Re: LSB specification for adding users and groups
- To: firstname.lastname@example.org
- Subject: Re: LSB specification for adding users and groups
- From: Rob Browning <email@example.com>
- Date: 01 Jul 1999 00:26:34 -0500
- Message-id: <firstname.lastname@example.org>
- In-reply-to: Daniel Quinlan's message of "Wed, 9 Jun 1999 12:18:54 -0700"
- References: <199906030134.SAA19907@sodium.transmeta.com> <Pine.LNX.email@example.com> <199906091918.MAA22042@sodium.transmeta.com>
Daniel Quinlan <firstname.lastname@example.org> writes:
> Okay, could I get someone to summarize the functional differences
> between the Debian adduser script and the "standard" useradd program
> (originally from the shadow utils and AT&T/SVR4)?
> My current plan is to base the LSB user/group specification on the
> useradd tools, mostly because it seems to be present on all Linux
> distributions, but also because it is used by lots of Unix applications
> and would make porting installation scripts to Linux easier.
> (I'd like LSB applications that install users and groups (using the LSB
> user/group specification) to avoid making things difficult for Debian.)
While we're at it, could we consider adding options to usermod to
support adding and removing a user to/from a set of groups? Right now
you can only use -G to specify a complete set of *replacement* groups
for the user, but that opens a nasty window between when you call
getgrent() repeatedly to find out which groups a user is currently in
and when you call usermod to add the user to that set of groups
plus/minus the new/deleted groups. During that window, some other
process could call usermod -G and clobber the update in progress.
I sent mail to Guy offering to help add this to the shadow-utils if it
turns out to be useful, but I haven't heard back yet.
In general, are simultaneous calls to usermod guaranteed to be atomic?
If not, then I think they should be (protected by a lockfile or other
Rob Browning <email@example.com> PGP=E80E0D04F521A094 532B97F5D64E3930