Re: Bug#621833: System user handling in packages: status of discussion
On Fri, 10 Jun 2011 at 10:12:20 +0100, Lars Wirzenius wrote:
> * Should packages also remove the contents of the system account's
> home directory? Should this be done upon package remove or purge?
I think packages should remove their state on remove/purge (as appropriate),
just like they do now. If that happens to mean removing the system account's
$HOME, that's fine; if that leaves the system account's $HOME behind, that's
fine too.
Many system users seem to have a home directory in /var/run, which isn't
guaranteed to exist after a reboot anyway.
IMO, if a system user's home directory is in /var (except for /var/www which
is weird[1]), it's part of the package state, not part of the user - if I purge
(say) sbuild, it's responsible for removing /var/lib/sbuild because that's
part of the sbuild package. The fact that it also happens to be the sbuild
user's home directory is irrelevant.
I notice that quite a few users in my laptop's /etc/passwd - ntp, saned,
Debian-ipw3945d, cupsys, festival, usbmux - have a nonexistent directory
/home/$USER as their $HOME. Is this a bad thing? Should there be a well-known
"lack of a home" directory, like /nonexistent (which is already ~nobody)?
I think it'd be wrong to delete files from areas reserved for the local admin's
control (/home, /srv, /opt, /usr/local, anything in /var/www that didn't come
from a package[1]) just because a pseudo-removed system user lives there - if
ftp's $HOME is /home/ftp and I purge a ftpd, I wouldn't want the ftpd's
maintainer scripts to delete /home/ftp (which is presumably some sort of
public file area and probably contains things I wanted to keep).
S
[1] because it's (a) the default web root for all of our web servers,
and (b) hard-coded into things like suexec, so it's likely to contain
local-administrator-created files
Reply to: