RE: .spamassin folder not created after bugfix #4932

[Jo for Groups and Lists]

With regards to my post on Sept 8, I have not seen any responses. No
one else is having this issue with the .spamassassin folder not
always being created for a new user?

This bit of code is mixing up the unix username for the last message
filtered [for a pre-existing SA user] rather than the username for
the current message being filtered [for a new SA user].


  # bug 4932: use the last default_userstate_dir entry if none of
the others 
  # already exist 
  $fname ||= $self-sed_path($default_userstate_dir[-1]); 


If I manually create the new user's /.spamassassin/ folder, the
user_prefs does get installed as expected. Or if 2 messages for this
same user come in immediately in sequence, the first message fails
to do it, but the second message will successfully cause the
creation of the folder and prefs file. Because the 'last' in this
case just happens to be the same user.

Jo 

.spamassin folder not created after bugfix #4932

[Jo for Groups and Lists]

Greetings! I am hoping someone can confirm if this is a bug or
desired behaviour? Or if something else is causing it to go astray?

Running SA 3.13
SPAMDOPTIONS=-d -c -m5 -H

Runs on a per user basis - i.e. users who want to use SA have this
code placed in 
  /home/user/domain-mail/.rc.local.init
--
DROPPRIVS=yes
:0fw
*  256000
| spamc
--

I am having an issue since upgrading from 2.64 to 3.13. I believe I
have narrowed down to this:
SpamAssassin.pm - sub get_and_create_userstate_dir

  # bug 4932: use the last default_userstate_dir entry if none of
the others 
  # already exist 
  $fname ||= $self-sed_path($default_userstate_dir[-1]); 

Below is an excerpt from maillog. The top part shows a message
successfully going thru for user 'dilucy' who has had SA installed
previously. The bottom portion shows a message going thru for user
'council' - a new SA user. In theory this message encountered by SA
should trigger the creation of council's /.spamassassin/ folder and
user_prefs file. This was not happening. Via testing I found that
the user_prefs would be copied over if I manually created the
/.spamassassin/ folder first. Hence the reason for the No such file
or directory error means the .spamassassin folder is inexistant...
Not getting created.

In the logs below you will note that I added some extra warnings to
assist my troublehooting.

What I found is that it is $fname in this sub is being assigned the
file for 'dilucy', the last user instead of the current user. Then
the test   if (!-d $fname)   appears positive and so it skips the
mkpath command. In then returns to the other sub and resumes $fname
value for user 'council', trying to copy the user_prefs in a non
existant folder. I also found that if I hammered off several email
messages addressed to the 'council' account such that 2 messages in
a row handled by SA were both for user 'council', the second message
will correctly cause the creation of both the /.spamassassin/ folder
and the user_prefs file. This is because presumably, the last user
in this case ('council') was coincidentally the same as the current
user ('council').

-
 
Sep 8 17:16:17 host spamd[1482]: spamd: connection from localhost
[127.0.0.1] at port 46608 
Sep 8 17:16:17 host spamd[1482]: spamd: setuid to dilucy succeeded 
Sep 8 17:16:17 host spamd[1482]: spamd: processing message
[EMAIL PROTECTED] for dilucy:665

Sep 8 17:16:20 host spamd[1482]: spamd: identified spam (19.7/4.0)
for dilucy:665 in 3.2 seconds, 1540 bytes. 
Sep 8 17:16:20 host spamd[1482]: spamd: result: Y 19 -
MSGID_FROM_MTA_ID,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_NJABL_DUL,RCVD_IN_S
ORBS_DUL,RCVD_IN_XBL,URIBL_JP_SURBL,URIBL_OB_SURBL,URIBL_SBL,URIBL_S
C_SURBL
scantime=3.2,size=1540,user=dilucy,uid=665,required_score=4.0,rhost=
localhost,raddr=127.0.0.1,rport=46608,mid=200609082116.k88LGFn90020
[EMAIL PROTECTED],autolearn=disabled 


Sep 8 17:16:23 host spamd[1482]: spamd: connection from localhost
[127.0.0.1] at port 46638 
Sep 8 17:16:23 host spamd[1482]: spamd: setuid to council succeeded 
Sep 8 17:16:23 host spamd[1482]: spamd: creating default_prefs:
/home/council/.spamassassin/user_prefs 
Sep 8 17:16:23 host spamd[1482]: config:
/home/council/.spamassassin/user_prefs is not a file 
Sep 8 17:16:23 host spamd[1482]: in sub_get_and_create_userstate_dir

Sep 8 17:16:23 host spamd[1482]: config: fname is
/home/dilucy/.spamassassin 
Sep 8 17:16:23 host spamd[1482]: config: /home/dilucy/.spamassassin
is a directory 
Sep 8 17:16:23 host spamd[1482]: config: cannot write to prefs file
/home/council/.spamassassin/user_prefs: No such file or directory 
Sep 8 17:16:23 host spamd[1482]: spamd: failed to create readable
default_prefs: /home/council/.spamassassin/user_prefs 
Sep 8 17:16:23 host spamd[1482]: spamd: processing message
[EMAIL PROTECTED] for
council:855 
Sep 8 17:16:23 host spamd[1482]: spamd: clean message (0.5/5.0) for
council:855 in 0.1 seconds, 955 bytes. 
Sep 8 17:16:23 host spamd[1482]: spamd: result: . 0 -
NO_REAL_NAME,NO_RELAYS
scantime=0.1,size=955,user=council,uid=855,required_score=5.0,rhost=
localhost,raddr=127.0.0.1,rport=46638,mid=200609082116.k88LGMMw0020
[EMAIL PROTECTED],autolearn=disabled
- 
I notice often several messages are handled by the same pid [1482]
even if different users? Could this be contributing to this issue,
and if so, what could you suggest to change to avoid that from
happening?


Many thanks in advance,
Jo