On Friday 19 December 2008, mouss wrote: >Gene Heskett a écrit : >> Stumbling around in the dark, I created that user, and chowned >> the /var/lib/spamassassin directory to that user:mail, made saupdate a >> member of group mail. > >Why? if you do random mixing of owners and groups, you'll end up making >your system more vulnerable than it would be if you run sa-update as root. > OTOH, if I run it as root, then the clients have no perms. Tell me a way around that please.
>> The key import complained about unsafe perms >> of /var/lib/spamassassin, but did import the keys I think: >> /var/lib/spamassassin: >> total 40 >> drwxr-xr-x 2 saupdate mail 4096 2008-12-19 08:26 . >> drwxr-xr-x 39 root root 4096 2008-12-19 00:22 .. >> -rw------- 1 saupdate saupdate 2783 2008-12-19 08:26 pubring.gpg >> -rw------- 1 saupdate saupdate 0 2008-12-19 08:26 pubring.gpg~ >> -rw------- 1 saupdate saupdate 0 2008-12-19 08:26 secring.gpg >> -rw------- 1 saupdate saupdate 1200 2008-12-19 08:26 trustdb.gpg > >This is ugly. use a subdirectory. for example >/var/lib/spamassassin/keys, and make this directory only accessible to >the sa-update user (mode 600). Humm, and spec that in the --gpghomedir argument I assume? >> But now 'su saupdate -c "sa-update --gpghomedir /var/lib/spamassassin" >> returns: >> [r...@coyote saupdate]# su >> saupdate -c "sa-update --gpghomedir /var/lib/spamassassin" >> gpg: WARNING: unsafe permissions on homedir `/var/lib/spamassassin' >> >> However, it did seem to do it, and do it nearly instantly as I now have >> the full menu of cf files present in that /var/lib/spamassassin directory. >> All dated today. >> >> I just checked /usr/share/spamassassin, and root:root owns all of those >> .cf files, which doesn't seem correct to me, is that correct/ok? > >yes, it is correct. files that should not be changed by "anybody" should >belong to root. > >> Now it looks like I have 2 more questions: >> >> 1. How do I fix the permissions that gpg is fussing about? > >see above (create a subdir...). > >> 2. And what do I do to my /etc/init.d/spamassassin script so it will use >> the newly fetched .cf files instead of the ones in >> /usr/share/spamassassin? > >once you successfully run sa-update, it should be ok. you can verify >that by runnin spamassassin -D. > >> FWIW the user who runs fetchnail/procmail is also a member of group >> 'mail'. >> >> Running spamassassin -D --lint as this new user gets a higher score for >> the test message than I get when running it as the current user does. >> >> As the user saupdate: >> [...] >> [12840] dbg: check: is spam? score=4.205 required=5 >> [12840] dbg: check: >> tests=MISSING_DATE,MISSING_HEADERS,MISSING_SUBJECT,NO_RECEIVED,NO_RELAYS >> [12840] dbg: check: >> subtests=__HAS_MSGID,__MISSING_REF,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__MSO >>E_MID_WRONG_CASE,__NONEMPTY_BODY,__SANE_MSGID,__TVD_BODY,__UNUSABLE_MSGID >> >> As the user gene: >> [12861] dbg: check: is spam? score=3.79 required=5 >> [12861] dbg: check: >> tests=BAYES_40,MISSING_DATE,MISSING_HEADERS,MISSING_SUBJECT,NO_RECEIVED,NO >>_RELAYS [12861] dbg: check: >> subtests=__HAS_MSGID,__MISSING_REF,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__MSO >>E_MID_WRONG_CASE,__NONEMPTY_BODY,__SANE_MSGID,__TVD_BODY,__UNUSABLE_MSGID >> >> The diff being BAYES_40 apparently. > >the user who runs sa-update does so to update the rules. not to scan >mail, update Bayes, ... etc. do not use it for that. > >the user who scans incoming mail should be used to train (his) bayes. As is being done now. > >> Thanks for any more guidance, I feel like I need a white cane at this >> point. :) > >as long as you are not a turkey, there aren't much risks these days :) Nah, just an old fart trying to keep busy. I may eat some turkey though. :) Thanks everybody. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) "I'm not a god, I was misquoted." -- Lister, Red Dwarf
