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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]