Michael Hudson wrote: > Would it work/how much risk would it be to create accounts with shell > /bin/false?
It seems that the pydotorg admins are worried about such a prospect. I believe this alone either won't work or won't be good enough (not sure which one): If you have /bin/false as login shell, and still manage to invoke /usr/bin/svnserve remotely, you can likely also invoke /usr/bin/cat /etc/passwd remotely (or download and build the root exploit via ssh). So you would have restrict the set of valid programs to *only* svnserve. This is possible, but difficult to manage (AFAIK). > (still faintly bothered by ~/.subversion/auth/svn.simple/*...) Indeed. I personally would prefer SSL client certificates. This is still tricky (where do you get the passphrase for the private key from (*)), but slightly better. Regards, Martin (*) In case you wonder, I'm personally using the following techniques here: - on windows, remove the passphrase from the private key/.p12 file, and encrypt the file through NTFS encryption. Then you don't need to enter a passphrase, but still nobody can steal the private key from your disk (as long as you are not logged in; the same holds for ssh-agent) - on Linux, my issue is that .subversion is on NFS, so any root user in our net can connect to the file. Therefore, I copy the .p12 file to /tmp/private_dir, and remove the passphrase there. No other machine can read the file (as /tmp is not exported), and the file goes away after machine shutdown latest (as tmp is cleaned on reboot). - again on windows, I'm working on teaching subversion the Microsoft certificate store. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com