Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 652110

Summary: mail-filter/spamassassin spamd init script overrides admin-provided --username, --groupname options
Product: Gentoo Linux Reporter: Gil Kloepfer <gbz>
Component: Current packagesAssignee: Philippe Chaintreuil <gentoo_bugs_peep>
Status: CONFIRMED ---    
Severity: normal CC: bug, jstein, mjo, proxy-maint
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Gil Kloepfer 2018-04-01 02:19:10 UTC
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.
Comment 1 Michael Orlitzky gentoo-dev 2018-04-02 13:25:37 UTC
(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.