[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
passwd(1), etc...
- 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
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