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

Quoting Alexander Gattin (arg@online.com.ua):
> IMHO it should be researched where/how is userdel
> used/scripted.

As the bug report mentions, most of the time in deluser. In Debian, at
least.

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

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.

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.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don''t trust Computers. They | Mailadresse
im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Hi!

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.
So it will delete user and leave group in place,
[when the group has other members in it], as far
as I remember the common behaviour [of userdel].
> 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.
Probably we should consider the following functional
split between adduser/deluser (i.e. high-level) and
useradd/userdel (low-level) tools:

* low-level tools should care of and keep the minimal
  consistency and integrity of the data that affects
  correct operation of these low-level tools
  themselves (so that e.g. results of useradd are
  revertable with userdel).
  I mean that useradd/userdell should only preserve
  integrity of /etc/passwd, shadow, group, gshadow and
  other most necessary files.
  These tools shouldn''t care much about home dirs,
  NIS/LDAP/whatever interoperability, umasks/perms,
  mail spool files, good/bad user/groupnames and other
  sort of high-level consistency checks.

* all policy and high-level consistency checks are
  "praerogativa" of high-level tools.

The same I state in bug #264879, although rather
implicitly.

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_).

-- 
WBR,
xrgtn

tags 295416 upstream
retitle 295416 userdel should not remove the user''s primary group is it
has other members
thanks

> 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.

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.
>   I mean that useradd/userdell should only preserve
>   integrity of /etc/passwd, shadow, group, gshadow and
>   other most necessary files.

I mostly agree here. 

> The same I state in bug #264879, although rather
> implicitly.
> 
> 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.
>From your statement above ("userdel should guarantee the integrity of
system files"), such behaviour should *not* happen. userdel should
only delete the primary group of the user *only* if it has no other
members.

So, in my opinion, this bug is still an upstream bug. An I tag it
accordingly (which I forgot to do, though it is marked as "forwarded")

I also give it a better title.

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