I've just reviewed the discussion so far, here's my best attempt
at a summary of the current status:
* To create an user, a maintainer script should call
"adduser --system foo". It is not necessary to wrap this in
a check for whether the user exists.
* When the package is removed, the user should be locked:
"lockuser foo".
* lockuser is a still-hypothetical tool, which needs to be added
to the adduser package. It is a wrapper around "usermod -L -e 1 foo".
* Similarly, adduser needs to be changed to unlock:
"usermod -U -e '' foo".
* Policy 9.2.2, the description of the 100-999 UID range for system
users, should be changed to mention when and how users need to
be locked. Perhaps by adding the following sentence to the end of
the paragraph: "When the package is removed, it should lock the
user it created using 'lockuser'."
* We need a lintian check to verify that packages create and lock
users properly.
* Once the lintian check is done, bugs on all packages that fail it
should be filed.
Have I understood the discussion correctly? Any corrections or
objections to the above?
Unclear to me are the following two points:
* Should packages also remove the contents of the system account's
home directory? Should this be done upon package remove or purge?
If this is to be done, should we also provide a tool for it, to
make sure everyone does it the right way? "clearuserhome foo"
would essentially be "find ~foo -mindepth 1 -exec rm '{}' +",
except it needs to delete directories as well, and should
possibly have protection against crossing mount points,
and perhaps verifying ownership of files before removing, etc.
* Is there consensus that adduser should get a --local option,
and if so, what should its semantics be, and should packages
start using it now? Or can this wait until there's an actual
need for --local, so that the precise semantics can be defined?
There's a fairly few packages that create users, so we should
be able to deal with them fairly easily later.
--
Freedom-based blog/wiki/web hosting: http://www.branchable.com/
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110610091220.ga3...@havelock.liw.fi
