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

[Alexander Gattin]

Hi!

On Sun, May 01, 2005 at 08:10:01AM +0200, Christian Perrier wrote:
> > Probably we should consider the following functional
> > split between adduser/deluser (i.e. high-level) and
> > useradd/userdel (low-level) tools:
> The most important split, imho, is that useradd/userdel and other
> low-level utilities are potentially shared among several Unices and
> Linux distros.
> 
> So, as Marc mentioned, care should be taken to keep them behave
> consistently among these.

Of course, this should be taken into account as long as
it doesn't create problem for Debian.

But, problems are inavoidable, considering the
direction taken by Tomasz. He tends to extend
functionality of usedadd/userdel thus shifting the
tools into high-level.

This interferes with my proposed policy (split
between high/lowlevel tools).

> For me, this forbids us (Debian maintainers) to patch them in any way
> to make their behaviour different in Debian.
> 
> But, we should also remember that we work with upstream, so we're
> likely to influence a change in the design.

Yes.

IMHO, the high/lowlevel conflict can be solved in
all-satisfactory way by introducing switches to
usedadd/userdel that make them skip "high-level
consistency checks" [thus switching the tools into
low-level explicitly].

For example, usedadd could use smth. like
"--force-badname" cmdline option.

I think this is what we need here and which will not
break compatibility.

> > P.S. please, keep in mind that bug #295416 is not about
> > deleting group which has other members in it.
> > The bug is about userdel removing group which is
> > _primary_ for someone else (not having other _members_).
> Not exactly. This is about userdel *always* deleting the primary group
> of the user it deletes, no matter whether this group is used by
> another user.

No, userdel really always _tries_ to delete a primary
group for user being deleted (and this is not
documented, unfortunately).

But of course userdel doesn't delete a group which has
other members in it:
> cherokee:~# groupadd bug295416
> cherokee:~# useradd -g bug295416 bug295416
> cherokee:~# useradd -G bug295416 other295416
// created with primary group "users" (by default)
> cherokee:~# getent group bug295416
> bug295416:x:1005:other295416

Let's delete "bug295416" user now:
> cherokee:~# userdel bug295416
> cherokee:~# getent group bug295416
> bug295416:x:1005:other295416

Here you see that the "bug295416" group is left in
place.

But in the next scenario we can clearly see a problem:
> cherokee:~# groupadd bug295416
> cherokee:~# useradd -g bug295416 bug295416
> cherokee:~# useradd -g bug295416 other295416
> cherokee:~# userdel bug295416
> cherokee:~# getent group bug295416
> cherokee:~# 
Here you see that "bug295416" group is deleted. But
it's still the primary group for other295416:
> cherokee:~# getent passwd other295416
> other295416:x:1007:1005::/home/other295416:

Here the integrity of /etc/passwd+/etc/group is broken,
because an entry in former refers to gid 1005 which is
absent from latter.

> >From your statement above ("userdel should guarantee the integrity of
> system files"), such behaviour should *not* happen.

Yes, thus I forwarded a message to Tomasz. There is a
bug in upstream, IMHO.

-- 
My best regards,
xrgtn