Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Derek Atkins wrote: > I've got a linux box running some applications that require > a "local account" (in /etc/passwd) to authenticate users. > > I did find a PHP script but it requires sudo which I consider unsafe. ... > $cmd .= "spawn /bin/su $user -c /usr/bin/passwd; "; Why do you consider sudo any less safe than the call to /bin/su $user? If this is ran as root, I'd think you've widened your exposure. If the process is already running as $user, then su is a noop (effectively) and should be removed. Your safest bet would be to place a copy of the change password script into each account's web space so it runs (assuming Apache) suexec as that user. > That same page also had a PHP function to call out to expect so that > you don't need sudo... So how did the sudo version accomplish the password change? Perhaps using the setpwent() system call? You should be able to achieve equivalent security to the passwd command by calling setpwent() from a small wrapper program (C, Perl, PHP) that runs setUID to root and verifies that the supplied $user matches the real UID. That way a user can only change their own password. (Of course you'll want to validate the data you accept before passing it on to setpwent().) Here's a perl module for calling setpwent(): http://search.cpan.org/~eestabroo/Passwd-Linux-1.2/Linux.pm Surprisingly the passwd command still doesn't seem to offer an interface conducive to automation, so using something like expect seems necessary, if you want to avoid making a syscall as root. I didn't see a Perl module that used the expect-style interaction with /usr/bin/passwd. Or a ready-made web UI for password changing. (Though I only searched modules at CPAN, and that's less likely to be packaged up as a module.) > If the user supplies an incorrect entry then the next entry gets > printed into my http error log... I'm not sure how the info is finding it's way to your error log (perhaps expect is sending it to to STDERR directly), as I don't see that in the script, but the script does seem dependent on logging to a temp file in order to validate that the operation succeeded. A better design would be to avoid files and directly work with the pipes to/from the process being controlled. Perhaps there is a PHP implementation of expect, rather than calling out to expect. There are several native equivalents for expect in Perl: http://search.cpan.org/search?query=expect&mode=module Plan B might be to create an expect script that provides a more automation-friendly interface (like accepting the user and pass via STDIN, and returning a unique exit code for each failure case), while avoiding the use of temp files. Your PHP code could then call that. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |