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

passwd(1), etc...



Any thoughts on re-doing passwd(1) without SUID?

I've got my shell machines running passwd, chfn, and chsh sans-SUID;
they're now simple clients to inetd services that authenticate (via Unix
passwords) and perform the password file changes. 

The result is 3 fewer SUID programs. There are some advantages of
implementing privileged code as a daemon; users have less control over the
environment the code runs in (ie, no environment to pass on, no control
over how the program is executed, etc). There is a fairly important
disadvantage, that being that you lose the implicit access control (users
don't need a shell to change their password) and need to rely on things
like TCP wrappers.

There's a precedent for this; lots of places are installing a piece of
Qualcomm code called "popasswdd", which implements the Eudora POP password
changing scheme. Qualcomm's code is a wrapper to passwd(1), and does only
password changes.

My implementation of this needs to be cleaned up. Most importantly, I only
handle local password changing (since I don't do YP or Kerberos). Since my
code replaces passwd(1), it's doing some things it shouldn't be - namely,
directly manipulating the password database.

I've found extremely useful a library function that takes a struct passwd
and commits it to the password database. Does anyone think it's worthwhile
to agree on semantics for this and include it in OpenBSD?

----------------
Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf_(_at_)_enteract_(_dot_)_com]
----------------
"If you're so special, why aren't you dead?"



Visit your host, monkey.org