The init script for spamd in mail-filter/spamassassin-3.4.1-r20 unconditionally provides a --username and --groupname option when not using SPAMD_RUN_AS_ROOT, overriding any admin-provided options in /etc/conf.d/spamd. Reproducible: Always Steps to Reproduce: 1. Edit /etc/conf.d/spamd and modify SPAMD_OPTS with your own --username= and/or --groupname= option 2. Do not set SPAMD_RUN_AS_ROOT to true 3. Start spamd 4. Note that spamd is running as user spamd, instead of the username that you provided Actual Results: My SPAMD_OPTS in /etc/conf.d/spamd is set to: SPAMD_OPTS="--max-children=5 --create-prefs --helper-home-dir --username=spamas --groupname=spamas" A 'ps -auxww' indicates spamd is started as follows: root 4320 16.6 1.9 175168 76780 ? Ss 20:38 0:01 /usr/sbin/spamd --pidfile=/run/spamd.pid --max-children=5 --create-prefs --helper-home-dir --username=spamas --groupname=spamas --username=spamd --groupname=spamd --daemonize spamd 4321 0.0 1.7 175168 72108 ? S 20:38 0:00 spamd child spamd 4322 0.0 1.7 175168 72108 ? S 20:38 0:00 spamd child The username provided in the init script effectively overrode the ones I provided. Expected Results: root 4768 18.8 1.9 175204 76672 ? Ss 20:46 0:01 /usr/sbin/spamd --pidfile=/run/spamd.pid --max-children=5 --create-prefs --helper-home-dir --username=spamas --groupname=spamas --daemonize spamas 4769 0.0 1.7 175204 72276 ? S 20:46 0:00 spamd child spamas 4770 0.0 1.7 175204 72276 ? S 20:46 0:00 spamd child The SPAMD_RUN_AS_ROOT=true setting in /etc/conf.d/spamd is well-intentioned, but is somewhat of a misnomer in the context of the init script, since what it is really doing is forcing a specific username/groupname in the options, and not really checking to see if the init script will actually start spamd as root, and not checking to see if username/groupname options are actually provided as options. Setting SPAMD_RUN_AS_ROOT=true when providing --username/--groupname in SPAMD_OPTS is a suitable workaround for this bug, however if the behaviour is ever changed to actually run spamd as root without some kind of warning, this could be quite dangerous. A more permanent fix, which should(?) also be accompanied by an installation warning when implemented, would be to provide two additional options in /etc/conf.d/spamd such as SPAMD_USER, SPAMD_GROUP that default to spamd/spamd (respectively) with comments indicating that the user/group can be changed from the default by setting those options, and that root is a dangerous and invalid selection that will "kill spamd" (as stated in /etc/init.d/spamd). Will provide "emerge --info" if requested. I don't think it is necessary for this particular bug, as it is pretty clear what is happening in /etc/init.d/spamd and from the description above.
(In reply to Gil Kloepfer from comment #0) > > The SPAMD_RUN_AS_ROOT=true setting in /etc/conf.d/spamd is well-intentioned, > but is somewhat of a misnomer in the context of the init script, since what > it is really doing is forcing a specific username/groupname in the options, > and not really checking to see if the init script will actually start spamd > as root, and not checking to see if username/groupname options are actually > provided as options. I get what you're saying here, but you're root: you can always invalidate your own expectations if you're clever enough. If you want to, you can open /usr/sbin/spamd with a text editor and make it play rap music =) Adding --username and --groupname flags to SPAMD_OPTS is one of those cases where I think you just have to know that it's going to interact weirdly with a variable named SPAMD_RUN_AS_ROOT. Shell script is too stupid to figure out what's actually going to happen -- and while the name isn't perfect, changing it would annoy people at this point. > A more permanent fix, which should(?) also be accompanied by an installation > warning when implemented, would be to provide two additional options in > /etc/conf.d/spamd such as SPAMD_USER, SPAMD_GROUP that default to > spamd/spamd (respectively) with comments indicating that the user/group can > be changed from the default by setting those options, and that root is a > dangerous and invalid selection that will "kill spamd" (as stated in > /etc/init.d/spamd). The init script actually used to work this way, but there was a problem. The "spamd" user requires some special set-up to work out of the box, and changing the value of SPAMD_USER and SPAMD_GROUP didn't really work. Afterwards, you had to perform a bunch of manual steps that opened you up to root exploits by the previous SPAMD_USER/SPAMD_GROUP. I have another idea that might work. Ultimately the issue is that the init script's username/groupname are passed after yours. When SPAMD_RUN_AS_ROOT is false, we wind up with a command-line that looks like... --pidfile=${pidfile} ${SPAMD_OPTS} --username=spamd --groupname=spamd Instead, I could switch it around so that we get, --pidfile=${pidfile} --username=spamd --groupname=spamd ${SPAMD_OPTS} and I think your SPAMD_OPTS will then override the default username/groupname. Would that work for you? There's probably a more heavy-duty solution involving group permissions, but if that's all it takes to make your life easy, it's no problem.
Ping?
(response to "Ping" comment) Still monitoring the bug and still using the workaround I mentioned originally. I'm not sure what special set-up is required for the default spamd user, since the only thing that is there is a blank home directory. Basically that's how the user/group that I had chosen is configured (some of my own older scripts depend on that user, which is why I didn't change over to the Gentoo default). I still think the SPAMD_RUN_AS_ROOT is a misnomer, but your explanation was a good one and it explains why it was called that. The reason I suggested SPAMD_USER/SPAMD_GROUP (and having it default to the intended Gentoo user/group) is because it would be consistent with what is done for other Gentoo packages, such as git (git-daemon), subversion (svnserve), lirc (irexec), and lighttpd (as examples). With each of those applications, you can likewise (proverbially) shoot yourself in the foot if you wish, but the option is there if you have a need for it. My only concern with having two --username/--groupname options and arranging them so the preferred one is last is that this assumes that the application will always work this way. It probably will, but if it were me I would not want to have code that depended on that behavior. Hopefully this is helpful. It was good to hear the explanation originally, but it seemed at the time like the workaround I was using would solve my specific issue in the best possible way going forward (and nobody else seemed to be dealing with that same issue).
(In reply to Gil Kloepfer from comment #3) > > My only concern with having two --username/--groupname options and arranging > them so the preferred one is last is that this assumes that the application > will always work this way. It probably will, but if it were me I would not > want to have code that depended on that behavior. Not that you can rely on people to follow a spec, but POSIX recommends that later repeated option flags should take precedence over earlier ones: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html Most C programs support that because it's the way getopt() works. If you're looping through the arguments and setting a variable whenever you see a --username option, then the last one will overwrite earlier ones. For that reason, I think it makes sense to put SPAMD_OPTS at the end of the list anyway, so that users can override them. I just wanted to be sure that it actually solves the problem for you in this case. (You can edit the init script temporarily to check.)
