Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 635790 - =mail-filter/spamassassin-3.4.1-r16 init script breaks file-system backed per-user configs
Summary: =mail-filter/spamassassin-3.4.1-r16 init script breaks file-system backed per...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Philippe Chaintreuil
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-29 13:36 UTC by Philippe Chaintreuil
Modified: 2017-11-05 20:47 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Chaintreuil 2017-10-29 13:36:42 UTC
The new 3.4.1-spamd.init-r1 breaks per-user file-system backed configs/bayes because of the added command_args="--username=spamd --groupname=spamd".  This forces all spamd/c processes to run as the spamd user instead of setuid'ing to the user per spamc run.  Therefore spamd can't create/open files from ~/.spamassassin/ because it doesn't have the permissions to do so.  Fully database backed setups don't have the issue since filesystem permissions don't come into play.

The short-term fix would be to remove the username & groupname args.  I presume mentioning those options in a default conf.d would help set DB backed people to be more setup for security.
Comment 1 Michael Orlitzky gentoo-dev 2017-10-29 13:47:58 UTC
Can't you just give the "spamd" user read-only access to the ~/.spamassassin directories that it needs to read? (Sorry if this is a stupid question.)
Comment 2 Philippe Chaintreuil 2017-10-29 13:54:40 UTC
Spamd creates these files & folders when they don't exists.  That would mean that every user's home directory would need to be writable by spamd to create the ~/.spamassassin/ folder.
Comment 3 Philippe Chaintreuil 2017-10-29 13:59:19 UTC
Forgot to mention the forum thread that first noticed this: https://forums.gentoo.org/viewtopic-t-1068032-highlight-.html

It was also happening on my system since upgrading.  Just removed the args to see if it fixes it.

Here's the docs for the args for ease of reference:

==============================================================================
       -u username, --username=username
           Run as the named user.  If this option is not set, the default
           behaviour is to setuid() to the user running "spamc", if "spamd" is
           running as root.

           Note: "--username=root" is not a valid option.  If specified,
           "spamd" will exit with a fatal error on startup.

       -g groupname, --groupname=groupname
           Run as the named group if --username is being used. If this option
           is not set when --username is used then the primary group for the
           user given to --username is used.
==============================================================================
Comment 4 Michael Orlitzky gentoo-dev 2017-10-29 14:15:52 UTC
(In reply to Philippe Chaintreuil from comment #2)
> Spamd creates these files & folders when they don't exists.  That would mean
> that every user's home directory would need to be writable by spamd to
> create the ~/.spamassassin/ folder.

Well that's certainly the case when spamd is run as root, so I don't think any security is lost be making $HOME writable by the "spamd" user. In essence, you can make "spamd" a superuser on your machine to get the old behavior back, but having a separate username lets you tighten things up if you want to: for example, you could pre-create those directories and set the correct permissions on them so that write access to $HOME is not needed.
Comment 5 Philippe Chaintreuil 2017-10-29 15:13:41 UTC
1.)  I'm far less concerned with "you could do X-Y-And-Z to fix that" with the fact we've broken a significant number of Gentoo spamassassin installs.  Any previous default install that didn't setup a SQL backend is broken when they upgrade because user configs are now not readable/createable.

2.)  Your proposal is fine for saying to someone in a forum, but not for a package installation/upgrade without forewarning.  It would seem that we'd either need an enews to explain the step-by-step of migrating or a script.  And as it currently stand even a new install won't work because we aren't supplying such files to skel.
Comment 6 Philippe Chaintreuil 2017-10-29 15:52:55 UTC
Removing --username and --groupname from the init script returned my system to regular processing.

I'd suggest either (A) Masking/destabilizing -r16 or (B) removing those args from the init script to get things back to the status quo in the immediate term.  We can then come up with migration plans for running spamd as a spamd user going forward.

Removing the args does not mean that individual users can't set those args in the /etc/conf.d/spamassassin file, nor that those whom have already done so would be forced back to spamd run as root.
Comment 7 Michael Orlitzky gentoo-dev 2017-10-30 02:16:42 UTC
The change in question was introduced on August 13, about two-and-a-half months ago, with spamassassin-3.4.1-r13. To put this in some perspective, we've had three people (including yourself) report problems since then, so it's not the end of the world.

Since this has been in the tree for so long, it's not as simple as "just go back to root." Anyone who is now relying on spamd being run as an unprivileged user would be (justifiably) unhappy if we switch the default back to root. For example, if spamd is executing some untrusted code, and we switch the default back to root, then anyone who can modify that untrusted code can exploit the situation gain root.

With those two things in mind, I see a couple ways forward.

1. Propose temporary workarounds for the people affected, and document long-term fixes.

If the problem is not terribly wide-spread, how many of the people affected are actually using the user_prefs files? Would adding "--nouser-config" to SPAMD_OPTS solve everyone's issue?

Again, if the problem is not terribly wide-spread, we could tell people to make "spamd" have UID=0 temporarily while they set the correct permissions for some other UID on everyone's home directory. Then when the permissions are correct, switch "spamd" back to the other UID. (This gets worse as more people are affected.)

Downgrading to -r8 (and maybe locally masking -r16) works as a temporary workaround, but if we do it, we have to weigh the pros and cons. How many people are affected by this issue, versus how many are affected by the things we've fixed between -r8 and -r16?

2. Add an option to the conf.d file, called something like SPAMD_RUN_AS_ROOT. Given that going from a restricted user to root can be dangerous, it would have to default to "false", but at least then users would be able to change it in a forward-compatible manner. This would still look like a breaking change to someone coming from -r8, but really, the breakage occurred 2.5 months ago, and running as "spamd" is the new status quo.

Offering the variable is easier in the short-term, but in the long-term, I think it's detrimental to support it. Using root to get read access to things is like doing "chmod -R 777" to fix permissions errors on your website -- it works, but there's a better way. Whether to take the quick-and-painful or long-and-drawn-out option is a judgement call based on how many people are affected and whether or not the workarounds suffice for them.
Comment 8 Philippe Chaintreuil 2017-10-30 20:41:04 UTC
Your point is well taken.

> Would adding "--nouser-config" to SPAMD_OPTS solve everyone's issue?

Would not solve the issue on my system; my users have changes in their configs.

> Using root to get read access to things [...]

It's not using root for read access, it's using root to issue setuid to reduce privileges to the user whom the spam is being processed for.

> [...] we could tell people to make "spamd" have UID=0 [...]

This is creating the very security hole you're concerned about on systems that don't have it, as spamd will cease to do the setuid if a --username is specified.


I still say that the stabilization of -r16 is invalid and should be returned to unstable via whatever mechanism until we address this issue.  -r16 rather silently breaks existing setups without warning and therefore is not stable.  It was only stabilized a few days ago, so anyone that was using it before already had it locally marked for install.

I would be fine with a SPAMD_RUN_AS_ROOT or similar flag in the conf as long as there's notice that it needs to be set in these situations (non-SQL backed, file-system backed per user configs/bayes).
Comment 9 Michael Orlitzky gentoo-dev 2017-10-30 20:55:04 UTC
(In reply to Philippe Chaintreuil from comment #8)
> 
> > [...] we could tell people to make "spamd" have UID=0 [...]
> 
> This is creating the very security hole you're concerned about on systems
> that don't have it, as spamd will cease to do the setuid if a --username is
> specified.

I see, thanks for pointing that out.


> I still say that the stabilization of -r16 is invalid and should be returned
> to unstable via whatever mechanism until we address this issue.  -r16 rather
> silently breaks existing setups without warning and therefore is not stable.
> It was only stabilized a few days ago, so anyone that was using it before
> already had it locally marked for install.

This is touchy, because for practical purposes, destabilizing r16 will revert stable users to r8, escalating the spamd process from non-root to root privileges again on those systems. And I honestly don't know if we're allowed to de-stabilize packages... I have a plan that should resolve the issue after a few days, though (see below).


> I would be fine with a SPAMD_RUN_AS_ROOT or similar flag in the conf as long
> as there's notice that it needs to be set in these situations (non-SQL
> backed, file-system backed per user configs/bayes).

I think this is the best solution. I'll add this to the r17 I have ready with the openssl-1.1 fix, and commit it ASAP. I'll add a pkg_postinst message telling people to read the conf.d file, and ask for an emergency stabilization of -r17. To the extent that we can stabilize r17 quickly, that will prevent the breakage from the r8 -> r16 upgrade.
Comment 10 Larry the Git Cow gentoo-dev 2017-11-01 18:55:53 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=45323735d6f772c7060aa794594a2d88d9560fa6

commit 45323735d6f772c7060aa794594a2d88d9560fa6
Author:     Michael Orlitzky <mjo@gentoo.org>
AuthorDate: 2017-11-01 03:14:31 +0000
Commit:     Michael Orlitzky <mjo@gentoo.org>
CommitDate: 2017-11-01 18:54:57 +0000

    mail-filter/spamassassin: new revision letting spamd run as root (systemd).
    
    In the previous revision (r18), support was added for running spamd as
    root through OpenRC. That was done using a new variable called
    SPAMD_RUN_AS_ROOT, defaulting to false. The choice to use a boolean
    variable -- as opposed to e.g. SPAMD_USER -- was made because passing
    "root" as the username to spamd kills it. Thus, SPAMD_USER=root would
    not have worked, and we instead test SPAMD_RUN_AS_ROOT to decide
    whether or not to specify a username/groupname at all.
    
    The same exact issue arises with systemd; however, systemd offers no
    way for us to test the value of SPAMD_RUN_AS_ROOT and act on the
    result! The SPAMD_USER proposal is dead in the water for the same
    reason, so a different approach was needed. The simplest thing that
    could work was to move the "--username" and "--groupname" flags out
    of the systemd service file, and into the SPAMD_OPTS variable. That
    way, users who know what they are doing can simply drop those flags.
    
    Closes: https://bugs.gentoo.org/635790
    Package-Manager: Portage-2.3.8, Repoman-2.3.3

 mail-filter/spamassassin/files/spamassassin.service-r4         | 10 ++++++++++
 mail-filter/spamassassin/files/spamassassin.service.conf-r2    |  2 ++
 ...assassin-3.4.1-r18.ebuild => spamassassin-3.4.1-r19.ebuild} | 10 ++++++----
 3 files changed, 18 insertions(+), 4 deletions(-)

Additionally, it has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2d55bc8f1afb8dc8f712ba139a860c828f52eb17

commit 2d55bc8f1afb8dc8f712ba139a860c828f52eb17
Author:     Michael Orlitzky <mjo@gentoo.org>
AuthorDate: 2017-11-01 03:05:53 +0000
Commit:     Michael Orlitzky <mjo@gentoo.org>
CommitDate: 2017-11-01 18:54:56 +0000

    mail-filter/spamassassin: new revision that lets spamd run as root (openrc).
    
    The r13 revision of spamassassin came with a new init script (and
    systemd service file) that runs spamd as the "spamd" user by default,
    and that choice is not configurable. There is however a legitimate use
    case for running spamd as root; namely, when local users have their
    configurations or bayes databases stored in their home directories on
    the local filesystem.
    
    This new revision adds back the ability to run spamd as root, through
    the SPAMD_RUN_AS_ROOT variable in the OpenRC service configuration
    file. This should suffice for the users who have reported problems so
    far, and a similar fix for the systemd service is on its way.
    
    The pkg_postinst phase of the ebuild alerts users to the new
    configuration variable.
    
    Bug: https://bugs.gentoo.org/635790
    Package-Manager: Portage-2.3.8, Repoman-2.3.3

 mail-filter/spamassassin/files/3.4.1-spamd.conf-r1 | 30 +++++++++++++++++
 mail-filter/spamassassin/files/3.4.1-spamd.init-r2 | 38 ++++++++++++++++++++++
 ....1-r17.ebuild => spamassassin-3.4.1-r18.ebuild} |  9 +++--
 3 files changed, 75 insertions(+), 2 deletions(-)}
Comment 11 Philippe Chaintreuil 2017-11-05 20:47:42 UTC
Just confirming, @mjo, -r19 works for me with the new conf flag enabled.  Thanks!