Re: Bug#621833: System users: removing them

[sean finney <seanius@seanius.net>]

Hi Lars,

On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
> > But shouldn't we say they _must_ lock package-specific system users
> > and groups when the package is removed ?
> 
> I think that's a good idea. Steve Langasek in the bug (#621833) and
> others agree, so I think there's a strong consensus on that.

I don't think I'd agree there, at least without also addressing:

 * It also needs to limit the scope to locally defined users (i.e. not
   fail when it is unable to lock an NIS/LDAP/etc account).
 * There needs to be a way to explicitly do that with adduser or a similar
   tool[1][2][3][4].

Also, we haven't discussed what should be done in the case of a user
account possibly shared between different packages, where any one of
them may create it and 1..N of them might be installed.  For example,
nagios/nrpe comes to mind, or maybe parallel installed postgres versions
and related tools.  Alternatively, if we strictly interpret what
Ian suggested to not include such packages, we should state that and/or
give alternate instructions for this case.


I second your original proposal though, that packages must not delete
system users that they have created.  I don't think anyone had objections
to that, and the question is whether things should be taken further.


	sean

[1] Assuming it must be done with one tool, it should also state "lock
    users with $thiscommand $theseoptions", and depend on "$thisversion"
	of the tool in question if the tool needs to be updated.
[2] And if "$theseoptions" are not specifically for the "local only case",
    we need a way to tell the difference between a "locking failed" error and
	a "user is remote" error.
[3] Or maybe instead of using a tool we have something like declarative
    users, where we state policy and farm it off to dpkg to implement?
[4] Whoa, footnotespam ftw, sorry.