Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Tom,

Quoting Tom Metro <tmetro-blu-5a1Jt6qxUNc at public.gmane.org>:

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

Well, the sudo command was:

  sudo (root) passwd $user

It's bad because:

1) it didn't require knowledge of the existing user password
2) it could be used to reset ANY password for any user

I.e., it was designed for an admin, not for end users to use.

> If the process is already running as $user, then su is a noop 
> (effectively) and should be removed.

The process is running as user Apache.

> 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 would be... challenging.   My plan was to just set up an:

  https://<hostname>/changepassword.php

>> 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

Nope.  See above:

  sudo passwd

> 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().)

Well, this is what I'm trying to accomplish via the PHP.

[snip]
>> 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.

I think it is...

I'm not all that interested in the issues of the logfile per se.  I
don't consider that to be a major drawback.   However printing
out the password info into the logs on any failure in the expect
script it DEFINITELY an issue...   Granted, it's only ME seeing
the logs, but I'd prefer not to have that info at all.

> 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

Maybe?

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

Kinda hard to do that via PHP I think...  I was hoping for help to
write an expect script that better deals with the actual errors that
can come.  For example, I know that the /bin/su command will provide
two potential outputs:

  1) Password:
  2) /bin/su: user <user> does not exist

But I couldn't figure out how to exit the expect script if it's #2.

Thanks!!

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord-DPNOqEs/LNQ at public.gmane.org                        PGP key available







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org