On Sun, May 01, 2011 at 03:06:00PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > > 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.
> >
> > I do object to telling maintainers they must not delete system users,
> > without also giving guidance on how and when to lock the accounts.
>
> Yes, I agree with this.
>
> > Sorry, no time at the moment to propose verbiage to reconcile this with your
> > concerns.
>
> I think the right thing to do would be to have deluser lock (rather
> than delete) system users when invoked in the way currently used by
> maintainer scripts. Provided that doesn't make interactive use of
> deluser break somehow.
I've been looking at how this might be accomplished right now, and
have these observations to make. (These are WRT my addition and
removal of the "sbuild" user in the sbuild package.)
1) Locking on removal.
This is as simple as doing (in postrm)
# Lock sbuild account.
usermod -U -e 1 sbuild
However, one does now need to consider how "unlocking" will occur
if the package is reinstalled, which I don't think has been covered
as yet:
2) Reinstallation.
I'm currently using this logic (in postinst)
# Create dedicated sbuild user
if ! getent passwd sbuild > /dev/null; then
adduser --system --quiet --home /var/lib/sbuild --no-create-home \
--shell /bin/bash --ingroup sbuild --gecos "Debian source builder" sbuild
fi
However, consider that if the account is locked, the user already
exists and no unlocking will occur, leaving the reinstalled
package broken. This logic is common to many packages.
I've added this after the above to unlock if locked:
# Unlock account in case it was locked from previous purge.
usermod -U -e '' sbuild
This appears to reverse the locking, via inspection of the
shadow record. However, "" isn't documented as a valid
value for EXPIRE_DATE (it's the default in /etc/default/useradd
though).
Given the need to consider unlocking as well as locking, I'm not sure
it's worth adding special support to deluser: the typical logic used
to create the user will be insufficient to unlock, so it's no less
the effort to add an explict unlock/lock to the maintainer scripts,
dropping use of deluser entirely.
I do agree that a --local option would be a valuable and useful
addition to the adduser and deluser etc. tools, even if currently
a no-op. However, due to the above I don't think that adding
special-case user locking to deluser is the correct course of action.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature