PHP script (or other webapp) to allow users to change their password

[Tom Metro]

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/