On Sat, Jan 18, 2020 at 6:50 PM Michael Orlitzky <[email protected]> wrote:
> On 1/18/20 7:21 PM, Rich Freeman wrote: > > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <[email protected]> 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 > > > > Let's restart: > > * The daemon DOES NOT need a home directory for its user. > * I DO NOT want to install anything to anyone's home directory. > * With respect to user.eclass, I'm proposing that /home be treated > EXACTLY THE SAME as it always has been. > > All I want to do is *set* a user's home directory to /home/foo. > Why wouldn't you set the homedirectory to /dev/null then? -A > > Some people want to configure amavis to launch a program like pyzor, > which uses per-user configuration files. If you want to do that, you > first log in as amavis, and run some command like > > $ pyzor discover > > which then finds some servers and creates configuration files for you in > $HOME/.pyzor. > > This is user configuration, not daemon configuration. It doesn't belong > in the daemon's working directory. In particular, you should not be > dicking around in the daemon's working directory when you run "su > amavis..." because what you're doing is irrelevant to the daemon. > > 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. > > 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. > > > > 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. > > > > 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. > >
