[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.
>
>--
>Hallvard