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