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: > ...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 see your point. This implementation still must have had to deal with some back-and-forth chat with the passwd program. How did it accomplish that, or did it just blindly pipe the password to passwd and hope for the best? >> 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. Ah, so that's why the su is required, and the expect script must have incorporated a step to respond to the password prompt produced by su. I missed that. >> 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. What I was describing was a separate program that you'd call from your PHP code. The purpose of it being separate is to 1. limit the scope of code that requires root, and 2. to provide an interface more friendly for automation than provided by passwd. You could, in fact, implement it by tweaking the source of passwd. The underlying system call, setpwent(), requires root, so no matter how you slice it - using passwd or something else - you need some code to run as root. (passwd is setUID to root.) >> 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 don't follow. All the heavy lifting would be done in the expect script. The code you showed was an embedded expect script. I'm just saying that you could move that to an external file and make it a bit more sophisticated. What I'm not sure about is how difficult it would be to make the expect script do what I described (plus adding the interaction with su). I tend to avoid specialty languages, like expect, as they inevitably have disappointing limitation compared to a general purpose language paired with a library. So if it was me, I'd use the Perl native expect library. I took a look at what would be required to code this with the Perl Expect library, and it's doable, but a pain. The API isn't very clean (derived from the original expect and TCL), you don't get a good indication of whether the command executed successfully, error handling in general doesn't seem to be done well, you'd need to do a lot of testing to make sure you handled all the possible error messages from the two programs you are running, and any expect-like solution requires black magic with ptys under the hood. (I saw a few modules that were layered on top of the Expect module and provided marginally cleaner APIs, and IPC::Run that provides a far different API, but nothing that helps address the other problems above.) It's a mess that I'd avoid, if you could. I'd take a look at modifying the source of passwd to accept its parameters from STDIN, and produce unique exit codes, or reimplement a minimalist passwd in Perl/C/PHP as a setUID root command with a similar interface, then call either from your PHP web UI. What would be nice is to have some sort of simple remote procedure call library that could be layered over something like System V IPC for calling functions in a child process. Such a thing probably exists... -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. |