[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Functions for user management
- To: tech_(_at_)_openbsd_(_dot_)_org
- Subject: Functions for user management
- From: Leif Pedersen <bilbo_(_at_)_smaug_(_dot_)_hobbiton_(_dot_)_org>
- Date: Fri, 28 Jul 2000 03:06:29 -0500 (CDT)
I'm nearly done with some functions to manage users without running
pwd_mkdb every 2 seconds. (I'll prob'ly post a link to them tomorrow.) I
wrote the following:
int pw_add(struct passwd *pwd, int flags);
int pw_modify(char *username, uid_t uid, struct passwd *new_pwd, int flags);
int pw_remove(char *username, uid_t uid);
They make all necessary mods to /etc/pwd.db, /etc/spwd.db, /etc/passwd,
and /etc/master.passwd and lock the databases with /etc/ptmp. They're
completely backwards compatable and keep the db's in perfect sync without
re-sorting the whole thing. This is necessary on a system with >10,000
users, and convenient on a 1000+ user system. (Mine has 50,000 now.
pwd_mkdb takes almost 2 hours to run. pwd.db is 21meg, spwd.db is 41meg,
master.passwd is 6.5meg, and /etc/passwd would be 3.5meg).
I don't have it check for duplicates, since a user may want to (stupidly
imo) use duplicate uids for root or something...so I left that up to the
programmer. The only bug is if you remove the first in a duplicate set of
uids, it'll lose the uid to username mapping for the ones that are left.
Same with duplicate usernames. But this seems irrelavent since you're not
really supposed to use duplicate identifiers anyway. The amount of time
it takes to search for the appropriate replacement is out of the question
as it would defeat the purpose of writing these at all. Also, pw_modify
can handle changing usernames or uids...last I checked chfn couldn't.
These only modify /etc/passwd if it exists, leaving the admin the option
of not having it. I don't like having it because it's too easy of a spam
The biggest timewaster is writing a new master.passwd...which isn't
something to be gotten around, but isn't bad anyway.
I don't have man page skills, so someone else must do that if it gets
What would be the clean way to return errors? Right now I'm returning
#define'd stuff like FILEERROR, NOTFOUND, LINETOOLONG, LOCKERROR, or
CORRUPTION...or 0 on success...since there's no errno's to match the
situation. FILEERROR leaves errno set to whatever open() complained
about. CORRUPTION should only happen if the db's are out of sync to begin
with (like if someone edits master.passwd outside of vipw).