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.
Description: Digital signature