On 7/7/14 7:38 PM, Martin Furter wrote: >> On Linux I see only the environment of my own processes. On OpenBSD I >> see only HOME and PATH for other users. So envvar seems to not be less >> secure than a password file.
Except that it shows in up for the root user for all commands regardless of user. For example with BSD style arguments on Linux: [[[ # ps xewww | grep postfix | grep -v grep 1930 ? Ss 1:14 /usr/lib/postfix/master manpage_directory=/usr/share/man queue_directory=/var/spool/postfix command_directory=/usr/sbin data_directory=/var/lib/postfix mail_owner=postfix OLDPWD=/etc/postfix sample_directory=/usr/share/doc/postfix/examples sendmail_path=/usr/sbin/sendmail setgid_group=postdrop readme_directory=no config_directory=/etc/postfix html_directory=no PATH=/bin:/usr/bin:/sbin:/usr/sbin LANG=C MAIL_CONFIG=/etc/postfix daemon_directory=/usr/lib/postfix mailq_path=/usr/bin/mailq PWD=/var/spool/postfix MAIL_LOGTAG=postfix newaliases_path=/usr/bin/newaliases ]]] I suspect we want to avoid the root user accidentally seeing passwords just from running ps, even if they do have to run ps with someone unusual options. Granted root can ignore file permissions with respect to reading the password from a file, but I think that a root user opening a file is a much more active level of snooping. I know as a root user I would avoid opening files unless I had a specific reason to do so. >> If you really want to improve security the only option is using stdin. >> >> I had a patch for that ready. But then people started wishing other >> things so I just implemented without thinking too much :) I don't like this patch for a couple of reasons. First it blocks any other interactive prompting. Not just prompting for authentication. Most notably all our conflict resolution prompting won't work with this functionality. For example (with your patch): [[[ svnadmin create repo svn co file://$PWD/repo wc cd wc echo foo > foo svn add foo svn ci -mm echo foobar > foo svn ci -mm svn up -r1 svn rm foo svn up --password - < /dev/null ]]] This forces users who want to script the authentication but not the conflict resolution to choose, insecure passwords or no interactive conflict resolution. Second it adds a magic value to a long standing argument that didn't have one. If the argument was expecting a path name I wouldn't think much of it because '-' is an expected magic value in that case. In this case the argument is expected to be the literal password. Using '-' for a password would be terrible but I don't see the benefit to doing this when we can add --password-file, which takes the '-' (allowing this usage) and allows reading from a file that can work with interactive conflict resolution. I realize that putting passwords into a file is far from perfect. You have to worry about permissions (which root can ignore) and possibly securely deleting the file when done (which is becoming far harder with SSDs). But I think it's a reasonable security tradeoff for still having stdin available for prompting. So I'd prefer your original patch with just --password-file.
