Bug 6995 - specify user to fall back for spamd instead of nobody
Summary: specify user to fall back for spamd instead of nobody
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: 4.0.0
Assignee: SpamAssassin Developer Mailing List
Depends on:
Reported: 2014-01-25 14:13 UTC by Matus UHLAR - fantomas
Modified: 2019-06-15 20:47 UTC (History)
6 users (show)

Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Matus UHLAR - fantomas 2014-01-25 14:13:28 UTC
when spamd is provided with a user name that is not found, spamd falls back to hardcoded "nobody".

Since "nobody" has no home directories on many systems (and it's not wise to create it), the admin should be able to choose other user that would be used as default, so he could maintain kind of default options, BAYES database etc.

Please provide option for specifying different user than "nobody" to fall back.
Comment 1 RW 2014-01-25 19:18:46 UTC
Do you mean the unprivileged user in "spamd -u", or the username passed to spamd by spamc?

Either way I don't see why it would be useful, it sounds like an option for something that shouldn't happen in the first place.
Comment 2 Matus UHLAR - fantomas 2014-01-26 18:07:09 UTC
The latter case. I'm using spamass-milter that passes destination username to spamc (in this case, after expantion by sendmail -bv), and the destination user may not exist (e.g. it's alias to remote address).
I do not think that spamass-milter should take care about the username, since it 
would require new code into it.

I believe there may be other cases where the username does not exist.

While I may agree that this is a situation that should not happen, the fallback is already implemented and 'nobody' is not always a good idea as I mentioned before.
Comment 3 Benny Pedersen 2014-02-04 06:41:02 UTC
if spamd is started as nobody, it cant run as user_prefs settings, so it only root to fallback to

saame reason that apache have one single thread that is owned by root in top, and other spawned as apache, even postfix have one master that runs as root, but services is never run as root

all services binding to lowports under 1024 will have to start as root and dropprivs after to be secure

just a reminder to not make this not work here
Comment 4 RW 2014-02-04 12:03:55 UTC
Benny, this has already been clarified. It's the user passed via the spamc-spamd protocol, not the user that spamd starts-up with or permanently drops down to with spamd -u.
Comment 5 Benny Pedersen 2014-02-06 14:18:55 UTC
okay my fault, is this still a spamassassin problem ?

would it not be mainer packagement way to setup spamd as running on non privileged user if only virtual users is needed in spamc ?


is spamd/spamc not supporting db based defaults for say nobody ?

just trying to understand why its a bug report here ?


i could remember i tryed get it to work, but at that time i used amavisd so the spamd/spamc was hard to get working for me
Comment 6 Kevin A. McGrail 2014-02-06 16:26:52 UTC
(In reply to Benny Pedersen from comment #5)
> okay my fault, is this still a spamassassin problem ?

It's a feature request not a problem.  
> would it not be mainer packagement way to setup spamd as running on non
> privileged user if only virtual users is needed in spamc ?

That's a good thought.  Make the terms nobody defined at the top of spamd.raw for a maintainer of packages to change rather than add a configuration option.  If a user wanted to change, they could modify spamd.raw (or spamd) and just change the config var in the script. 

Comment 7 Benny Pedersen 2014-02-06 17:48:39 UTC
okay, good, its just that as a gentoo maintainer i would not change raw files, but provide needed changes in ebuild to go virtual_user or system_user where it cant be enabled both at the same time

dont know how other distors handle it, but this was my thought about it

note: gentoo devs does not change tarballs, unless its really needed, and if it is it will be a patch to show the problem it solves :)