[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Patch: 'ldapmodify -y file' reads password from file (ITS#2031)

There are a few reasons why I prefer all octets of the
passfile to be significant to the -y option.  First and
formost is that all octets of a file loaded via the LDIFv1
URL mechanism are significant (and all octets
of userPassword are significant).

Other reasons include portability.  Newlines differ from
operating system to operating system.  I rather avoid
platform specific passfiles.

There are many passwords which cannot be entered using
-w and/or -W.  passfile should support all possible password
values.  Which means it should support any arbitrary sequence
of octets.  That is, if the user happen to have a password
comprised of various newline characters, she can use -y
to provide that password to the LDAP tools.

To aid creation of passfiles (without the newline), maybe we
should profile example scripts for their creation in contrib?

At 07:46 AM 2002-08-30, h.b.furuseth@usit.uio.no wrote:
>Kurt D. Zeilenga writes:
>> One of the nice things about using the whole contents of a file
>> is that one can use dd if=/dev/random of=/srv/passwd to create
>> a password file and use userPassword:< file:///srv/passwd to add
>> it to the directory and use -y in scripts.
>You can still do that if the terminating newline, if any, is
>considered insignificant.
>> For those who want to use it for simple passwords, the
>> file can easily be created using:
>>   echo -n 'secret' > /srv/passwd
>I.e. you have to know Unix in order to create this file:-(
>OTOH, the file can not be created using vi, which silently adds
>a newline.  Nor with emacs if `require-final-newline' is t.
>I think we'd see pleny of error reports from people who have put
>the password in a file as specified but can't get it to work.
>> where echo is the builtin version, so args are not exposed
>> to ps(1).
>They are exposed in .history or .bash_history.  .bash_history is even
>created with the user's umask instead of mode 0600.  The maintainter
>claims this is not a bug.  Maybe he'll change his mind if enough other
>people (than me) report that as a bug, bug I'm not holding my breath.