[Pkg-shadow-devel] Bug#295416: Deleting a user group in userdel should only be done if the group is empty

Alexander Gattin arg@online.com.ua
Sat, 7 May 2005 21:56:27 +0300


Hello, Marc!

On Sat, Apr 30, 2005 at 08:14:14PM +0200, Marc Haber wrote:
> On Tue, Apr 19, 2005 at 07:15:51AM +0200, Christian Perrier wrote:
> > Marc, CC'ing youš: what is your opinion about the "right" behaviour
> > from userdel (from deluser point of view) when a user group has an
> > extra member and not the user him/herself only?
> > 
> > -userdel should fail and not remove the user groups
> > 
> > -userdel should remove the user group but not fail, just issue a
> >  warning
> 
> I think that basically userdel should behave as it behaves everywhere,
> to keep people who want (or need) to use the low-level tools are not
> in for any surprises.

I spent some time during previous week to look at
useradd in other unices. What I found, in particular,
is that in FreeBSD, e.g. there's no useradd/userdel at
all. Their high-level tools are adduser(8)/rmuser(8) and
low-level is pw(8):
  http://www.freebsd.org/cgi/man.cgi?query=adduser&section=8
  http://www.freebsd.org/cgi/man.cgi?query=rmuser&section=8
  http://www.freebsd.org/cgi/man.cgi?query=pw&section=8

useradd(1M)/userdel(1M) are present in Solaris and are
  http://docs.sun.com/app/docs/doc/816-5166/6mbb1kqjh?a=view
  http://docs.sun.com/app/docs/doc/816-5166/6mbb1kqji?a=view
very similar to their shadow's counterparts, except -A,
-P, -R, -p and -K/-O options.

What resembles what, that's the question! ;)

And of course, there were pre-shadow useradd/userdel in
Linuces (and that useradd used smth. like
/etc/default/useradd instead of current
/etc/login.defs), syntax of which is unknown to me (I
did not find the relevant manpages). But these are no
more in use, IMHO.

> Deluser does things before calling userdel, so I think that userdel
> should do what has been requested as good as possible without failing.
> This is most likely the way that won't have the system end up in a
> badly inconsistent state.

What's most relevant here is when userdel _fails_ to
remove an account and what are its exit codes.
For example, Solaris defines 0, 2, 6, 8, 10, 12 exit
codes, two of them (0 and 10) mean that account is
deleted.

In shadow's userdel, we have exit code of 1 in addition
to the above, which means "can't update password file"
and undocumented "13" exit code (memory allocation
error?).

Primary group for user is always deleted when it has
the same name as login name and _contains no members_.
userdel silently returns 0 in this case.

We should check what Solaris does in this case, but I
think it does exactly the same, maybe -bug#295416, i.e.
restrains from deleting someone else's primary group.

So, except fixing this behaviour, do you want userdel
to output a warning when it can't delete a group,
because it has members/is primary for someone else, for
example?
(I don't think you want to introduce other exit
codes...)

P.S. Probably, in UNIX world the utils for
adding/removing/modifying user accounts are just too
different for operator to expect any similarity in
their behaviour.

-- 
Just my 5 cents worth.
WBR,
xrgtn