On Sat, Jan 18, 2020 at 9:50 PM Michael Orlitzky <m...@gentoo.org> wrote: > > On 1/18/20 7:21 PM, Rich Freeman wrote: > > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <m...@gentoo.org> wrote: > >> > >> But now users have to follow one more step (create /home/amavis) when > >> setting up amavisd-new. Is the QA check really assuring a quality user > >> experience here? > >> > > > > Lots of daemons need a home directory for their users, and usually > > they manage to get by in /var/lib. It really seems like a bad > > practice to start having packages creating stuff in /home. Certainly > > I don't want random daemons sticking stuff in /home, which I manage > > > > * The daemon DOES NOT need a home directory for its user. > * I DO NOT want to install anything to anyone's home directory.
My concern isn't with installing stuff to "anyone's home directory." My concern is with creating ANYTHING in /home. Daemons are local users. There is no guarantee that /home is a local filesystem. Heck, there is no guarantee that /home is even mounted when portage is running. Portage shouldn't be touching /home at all. With stuff like automounted or encrypted home directories and systemd-homed and so on it seems like it is even more important to avoid sticking stuff in /home (and this is hardly something started by systemd - stuff in /home that is non-static has been a thing for some time - certainly it was happening in the 90s on some IRIX workstations I used). > * With respect to user.eclass, I'm proposing that /home be treated > EXACTLY THE SAME as it always has been. I'm not aware that it was ever considered good practice to stick stuff in /home. I suspect it just wasn't on QA's radar in the past. > > All I want to do is *set* a user's home directory to /home/foo. You don't just want to "set" it. You want to create the directory, which is modifying the filesystem (otherwise, why have a .keepdir?). And setting a home directory to something that doesn't exist doesn't seem like an improvement unless it is /dev/null. I get though that the daemon itself doesn't use the home directory, and that you just want it for configuring other stuff it might launch. > Spamassassin itself is a better example than amavis. We already set the > spamd user's home directory to /home/spamd with user.eclass. We don't > install anything there, and this works fine. If a human logs into that > account and generates some configuration in ~/.spamassassin, then it's > within the spirit of the FHS to have that data stored in /home. Looks like we might have another package to deal with, and perhaps others as well, depending on what comes out of this thread. > Now, with GLEP 81, we get a QA warning for that, because the eclass > installs a keepdir file there. I would like things to remain exactly as > they are, with no QA warning. Otherwise, we have to tell users to move > /home/spamd to /var/lib/spamd-home or something stupid like that. I can > think of no good reason to do so. Well, you won't get QA warnings from the tinderbox if the default home isn't under /home. Users who already have the home there might get warnings at install time. They can just ignore them. You could output an einfo to explain the situation to the user. If they're fine with /home then they can ignore the warning, and if they want to move it they can do so. I'll also note that GLEP 81 itself is silent on WHERE home directories should be placed. If some sort of definitive answer comes out of this thread the GLEP should probably be updated to reflect this, unless there is a better place to put it. Seems like the fact that this practice was undocumented in the past is part of how we got to where we're at. > > It seems like the straightforward solution is to stick everything in > > /var/lib/amavis, and fix things so that everything has the right > > permissions regardless of install order. > > Please stop telling people to do this. Calling chown on the live > filesystem is rarely safe, and I already fixed one root exploit (bug > 630836) in the amavisd-new ebuild from the last guy who tried to adjust > wrong permissions after the fact. That bug appears to be restricted. Perhaps it is embargoed? If not, then it probably shouldn't be restricted, especially if already fixed and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that this has anything to do with you most likely). Portage should provide a safe mechanism to fix permissions. Or we should just avoid nesting user home directories inside directories that will be written to by that user. If this is the same hard-linking concern as with tmpfiles.d then somebody really just needs to fix POSIX. :) But as a workaround just avoiding nesting seems like the simpler solution... Just on a side note, I'm just stating an opinion here. I'm not in QA. Nobody should be construing my posts as "telling people" to do anything. And I do realize that you're just inheriting a situation that goes back probably quite a long time - please don't take anything as a personal criticism. Maybe this stuff wasn't entirely thought out in the past, but going forward we should try to come up with the best solution, and then try to find the most reasonable way to get from here to there. > > Another option is to have /var/lib/amavis/home and /var/lib/amavis/work. > > This is better-looking than /var/lib/amavis-home, but it's still > violating the spirit of the FHS to avoid triggering a warning on a dummy > file. Do you have a more FHS-compliant suggestion? Clearly /home isn't particularly FHS-compliant: /home is a fairly standard concept, but it is clearly a site-specific filesystem. The setup will differ from host to host. Non-login accounts created for administrative purposes often have their home directories elsewhere. This actually seems like a bit of an FHS gap. IMO /var/lib is the lesser evil here, but if there is something else more FHS-appropriate that could work. FHS says that users shouldn't have to touch /var/lib to configure a daemon, but as you've pointed out this isn't about configuring the daemon itself, but rather helpers that it might run after the user configures it to do so. -- Rich
