1 |
On 1/19/20 6:29 AM, Rich Freeman wrote: |
2 |
> |
3 |
> Daemons are local users. There is no guarantee that /home is a local |
4 |
> filesystem. Heck, there is no guarantee that /home is even mounted |
5 |
> when portage is running. Portage shouldn't be touching /home at all. |
6 |
> With stuff like automounted or encrypted home directories and |
7 |
> systemd-homed and so on it seems like it is even more important to |
8 |
> avoid sticking stuff in /home (and this is hardly something started by |
9 |
> systemd - stuff in /home that is non-static has been a thing for some |
10 |
> time - certainly it was happening in the 90s on some IRIX workstations |
11 |
> I used). |
12 |
|
13 |
If you're sharing /home, you're also sharing users. At that point, the |
14 |
daemon user is no longer local. The rest, with all due respect, is FUD. |
15 |
This is a home directory for an account that a human being will log |
16 |
into, where he interactively creates per-user configuration files. If |
17 |
that doesn't go in /home, what does? |
18 |
|
19 |
If you're sharing $HOME for all of your users, why wouldn't you want to |
20 |
share $HOME for this user? Trying to "hide" this one particular home |
21 |
directory is second-guessing the administrator. |
22 |
|
23 |
|
24 |
> You don't just want to "set" it. You want to create the directory, |
25 |
> which is modifying the filesystem (otherwise, why have a .keepdir?). |
26 |
> And setting a home directory to something that doesn't exist doesn't |
27 |
> seem like an improvement unless it is /dev/null. |
28 |
> |
29 |
> I get though that the daemon itself doesn't use the home directory, |
30 |
> and that you just want it for configuring other stuff it might launch. |
31 |
|
32 |
The keepdir is an implementation detail; that's my whole point here. I |
33 |
don't need the directory (although it would be nice) and I really don't |
34 |
need the keepdir file. But the GLEP eclass calls keepdir and the QA |
35 |
warning flags it. |
36 |
|
37 |
I'm leaning towards deleting the keepdir file and the directory from $D |
38 |
to avoid the warning. We can tell people to create the home directory |
39 |
themselves on the wiki. I don't want to selectively ignore the warning; |
40 |
if it's generating false positives (I think it is), then the warning |
41 |
should be fixed. |
42 |
|
43 |
I like your /var/lib/amavis/{home,work} suggestion second-best, but the |
44 |
most appropriate place for the home directory of an account that will be |
45 |
used interactively by a human (even if it's also used to start a daemon) |
46 |
is under /home. For example I do want to back up that home directory, |
47 |
but I don't want to back up the working directory. |
48 |
|
49 |
|
50 |
> That bug appears to be restricted. Perhaps it is embargoed? If not, |
51 |
> then it probably shouldn't be restricted, especially if already fixed |
52 |
> and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that |
53 |
> this has anything to do with you most likely). |
54 |
|
55 |
It's embargoed because security-audit@ goes to /dev/null, but the bug is |
56 |
already fixed. (If anyone can un-embargo my other 50 ancient security |
57 |
bugs, just let me know who to bribe.) |
58 |
|
59 |
|
60 |
> Portage should provide a safe mechanism to fix permissions. Or we |
61 |
> should just avoid nesting user home directories inside directories |
62 |
> that will be written to by that user. |
63 |
> |
64 |
> If this is the same hard-linking concern as with tmpfiles.d then |
65 |
> somebody really just needs to fix POSIX. :) But as a workaround just |
66 |
> avoiding nesting seems like the simpler solution... |
67 |
|
68 |
Essentially yes, but hard links aren't the only problem. It's unsafe to |
69 |
do anything as root in a user-controlled directory. POSIX can't fix |
70 |
that, and that means that portage will never be able to fix permissions |
71 |
(or do anything else) within a user-controlled directory safely. |