SpamAssassin 3.2.3 looks for user_prefs in the wrong place

["R. Portier" <rp...@phys.ens.fr>]

Hello,

Context
=======
I use SpamAssassin 3.2.3 on Debian 4.0 i386

spamd is invoked with options : -u spamassassin -m 5 -H /etc/spamassassin
(-D -u spamassassin -m 5 -H /etc/spamassassin when in debug mode)

The home for user spamassassin is /none (this directory does not exist).


my /etc/procmailrc :
--------------------
# SpamAssassin
:0fw
* < 200000
| /usr/bin/spamc



my /etc/spamassassin local.cf :
-------------------------------
required_score 5.0
rewrite_header subject *****SPAM*****
#
bayes_auto_learn 0
bayes_file_mode 0777
use_auto_whitelist 0
allow_user_rules 1
#
trusted_networks 129.199.112/20 129.199.96/24
internal_networks 129.199.112/20
#
dcc_path /usr/bin/dccproc
pyzor_options --homedir /etc/mail/spamassassin
razor_config /etc/mail/spamassassin/.razor/razor-agent.conf


Issue
=====
The user_prefs files for my users are not taken into account by SpamAssassin.

When invoking SpamAssassin in debugging mode, I get :

(...)
Dec 20 10:56:43 xxxxxxxx spamd[10239]: prefork: ordered 10257 to accept
Dec 20 10:56:43 xxxxxxxx spamd[10239]: prefork: sysread(7) not ready, wait
max 300 secs
Dec 20 10:56:43 xxxxxxxx spamd[10257]: spamd: connection from localhost
[127.0.0.1] at port 60395
Dec 20 10:56:43 xxxxxxxx spamd[10257]: config: read_scoreonly_config:
cannot open "/none/.spamassassin/user_prefs": No such file or directory
Dec 20 10:56:43 xxxxxxxx spamd[10257]: info: user has changed
Dec 20 10:56:43 xxxxxxxx spamd[10239]: prefork: child 10257: entering state 2
Dec 20 10:56:43 xxxxxxxx spamd[10239]: prefork: new lowest idle kid: 10258
Dec 20 10:56:43 xxxxxxxx spamd[10257]: config: mkdir /none/.spamassassin
failed: mkdir /none: Permission denied at
/usr/share/perl5/Mail/SpamAssassin.pm line 1576
Dec 20 10:56:43 xxxxxxxx spamd[10257]: config: Permission denied
Dec 20 10:56:43 xxxxxxxx spamd[10257]: bayes: no dbs present, cannot tie
DB R/O: /none/.spamassassin/bayes_toks
Dec 20 10:56:43 xxxxxxxx spamd[10257]: config: score set 1 chosen.
Dec 20 10:56:43 xxxxxxxx spamd[10257]: spamd: running as uid 110
Dec 20 10:56:43 xxxxxxxx spamd[10257]: dns: name server: xxx.xxx.xxx.xxx,
LocalAddr: 0.0.0.0
Dec 20 10:56:43 xxxxxxxx spamd[10257]: message: main message type: text/plain
Dec 20 10:56:43 xxxxxxxx spamd[10257]: spamd: processing message
<47...@xxxxxxx> for lambda:110
Dec 20 10:56:43 xxxxxxxx spamd[10257]: bayes: no dbs present, cannot tie
DB R/O: /none/.spamassassin/bayes_toks
Dec 20 10:56:43 xxxxxxxx spamd[10257]: received-header: parsed as [
ip=127.0.0.1 rdns=localhost helo=localhost by=xxxxxxxxxxxx ident= envfrom=
intl=0 id=0B4B457A0E auth= msa=0 ]
(...)

So SpamAssassin seems to be looking for the user_prefs file in
/none/.spamassassin/ !

When spamd is running as root (options : -m 5 -H /etc/spamassassin), it
works properly (ie the user_prefs file is looked for in
/home/<user>/.spamassassin/, is found, and is properly processed).


Is it a SpamAssassin bug, or am I doing something improperly ?


Regards.

Re: SpamAssassin 3.2.3 looks for user_prefs in the wrong place

[Matt Kettler <mk...@verizon.net>]

Remy PORTIER wrote:
> Hello,
>
> Thank you for your answer.
>
> I agree with you, but there is still something puzzling me.
>
> I have an old SpamAssassin 3.0.3 running on another server.
> Pretty much the same configuration (running as user spamassassin,
> allow_user_prefs 1, ...).
> This old version of SpamAssassin does manage to find the user_prefs files
> of my users.
>
> Do you know which version of SpamAssassin made this impossible (possibily
> as a consequence of a security fix) ?

The only way that's possible at all is if your using SQL or virtual
configuration dirs.

If you're using real user accounts, with real home directories, it's
impossible.

Re: SpamAssassin 3.2.3 looks for user_prefs in the wrong place

[Remy PORTIER <po...@phys.ens.fr>]

Hello,

Thank you for your answer.

I agree with you, but there is still something puzzling me.

I have an old SpamAssassin 3.0.3 running on another server.
Pretty much the same configuration (running as user spamassassin,
allow_user_prefs 1, ...).
This old version of SpamAssassin does manage to find the user_prefs files
of my users.

Do you know which version of SpamAssassin made this impossible (possibily
as a consequence of a security fix) ?

Regards.


Matt Kettler wrote:
> R. Portier wrote:
>> Hello,
>>
>> Context
>> =======
>> I use SpamAssassin 3.2.3 on Debian 4.0 i386
>>
>> spamd is invoked with options : -u spamassassin -m 5 -H /etc/spamassassin
>> (-D -u spamassassin -m 5 -H /etc/spamassassin when in debug mode)
>>
>> The home for user spamassassin is /none (this directory does not exist).
>>
>>
>>   
> <snip>
>> Issue
>> =====
>> The user_prefs files for my users are not taken into account by SpamAssassin.
>>   
> 
> Well, you've forced spamd to always run as the user "spamassassin" so
> that user's environment will ALWAYS be used, no matter who calls
> spamassassin.
> 
> In order for individual user prefs to occur, spamd must be running as
> root, so that it has sufficient rights to setuid itself to the user
> calling spamc.
> 
>> So SpamAssassin seems to be looking for the user_prefs file in
>> /none/.spamassassin/ !
>>
>> When spamd is running as root (options : -m 5 -H /etc/spamassassin), it
>> works properly (ie the user_prefs file is looked for in
>> /home/<user>/.spamassassin/, is found, and is properly processed).
>>
>>
>> Is it a SpamAssassin bug, or am I doing something improperly ?
>>   
> Not a bug. That's by design, and by security requirements of the OS itself.
> 
> The normal user "spamassassin" doesn't have rights to setuid itself to
> arbitrary users without a password, only root has those rights. Once
> spamd setuid's itself to "spamassassin" it can't go back and re-setuid
> itself run as someone else, as the OS would simply deny it.
> 
> 

-- 
   Rémy PORTIER      -  Département de Physique - Ecole Normale Supérieure
Ingénieur Recherche  -  24, Rue Lhomond - 75005 PARIS - France
     --oOOo--        -  Tél : 01.44.32.25.49
"Not everything that can be counted, counts and not everything that counts
can be counted."  --  Albert EINSTEIN

Re: SpamAssassin 3.2.3 looks for user_prefs in the wrong place

[Matt Kettler <mk...@verizon.net>]

R. Portier wrote:
> Hello,
>
> Context
> =======
> I use SpamAssassin 3.2.3 on Debian 4.0 i386
>
> spamd is invoked with options : -u spamassassin -m 5 -H /etc/spamassassin
> (-D -u spamassassin -m 5 -H /etc/spamassassin when in debug mode)
>
> The home for user spamassassin is /none (this directory does not exist).
>
>
>   
<snip>
>
> Issue
> =====
> The user_prefs files for my users are not taken into account by SpamAssassin.
>   

Well, you've forced spamd to always run as the user "spamassassin" so
that user's environment will ALWAYS be used, no matter who calls
spamassassin.

In order for individual user prefs to occur, spamd must be running as
root, so that it has sufficient rights to setuid itself to the user
calling spamc.

> So SpamAssassin seems to be looking for the user_prefs file in
> /none/.spamassassin/ !
>
> When spamd is running as root (options : -m 5 -H /etc/spamassassin), it
> works properly (ie the user_prefs file is looked for in
> /home/<user>/.spamassassin/, is found, and is properly processed).
>
>
> Is it a SpamAssassin bug, or am I doing something improperly ?
>   
Not a bug. That's by design, and by security requirements of the OS itself.

The normal user "spamassassin" doesn't have rights to setuid itself to
arbitrary users without a password, only root has those rights. Once
spamd setuid's itself to "spamassassin" it can't go back and re-setuid
itself run as someone else, as the OS would simply deny it.