[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: tech_(_at_)_openbsd_(_dot_)_org
- Subject: passwd(1), etc...
- From: "Thomas H. Ptacek" <tqbf_(_at_)_enteract_(_dot_)_com>
- Date: Fri, 1 Aug 1997 04:09:47 -0500 (CDT)
- Reply-to: tqbf_(_at_)_enteract_(_dot_)_com
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
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