On 01/27/2017 04:15 PM, Michał Górny wrote:
>
>> * users-update: cleanup can be done with --depclean now.
>
> Err, cleanup is never easy. You shouldn't really remove a user if it
> owns any files. I guess you could abuse pkg_prerm() for that but
> depclean will be terribly slow then.
>
What are our options if the user uninstalls a package that had its own
system user, and that system user still owns some files? Here are the
first few that come to my mind:
1) Leave the user there but uninstall the sys-user/foo package. This
is basically what we do now.
2) Bail out of pkg_prerm and tell the user to clean up those files.
3) Kill off the user anyway and leave the files.
The problem with (1) is that every user on the system is a liability,
and they never go away. If you test-compiled postgresql once five years
ago, there's still a "postgres" user with a shell on your system today.
Is the password locked? If not, is it strong? I have to ask the same
question about every other junk user in my /etc/passwd. There's also no
easy way to figure out which users are still needed at a later point.
The problem with (2) is that it's slow and annoying. Telling the user to
call "chown" on those files isn't safe, but I guess we could output a
"find ... -delete" command to be copy/pasted. We could also arrange
things so that if the user gets rid of the system user/group himself,
then the uninstall would succeed: basically a shut-up-portage override.
It'd still be horribly slow though.
The problem with (3) is that if some new user -- let's say "nobody" --
gets added to the system, it could be assigned a (previously removed)
UID that owns sensitive files. This would be abated by hard-coding UIDs
instead of taking the first available.
Hard-coding UIDs comes with its own set of problems though. It doesn't
totally solve the problem in (3), because users added outside of portage
could still be assigned a UID that owns files. And how do we guarantee
that a hard-coded UID won't be usurped? Some crappy build system could
throw a UID 80 onto the system and the user might never know until it
conflicts with apache. And right now we've got UID_MIN=1000 in
login.defs -- are we sure that we'll never have more than 1,000 sys-user
packages?
