On Mon, 5 Mar 2018 19:27:02 -0700
Amir Caspi wrote:

> Hi all,
>       Just FYI, for those of you who use DecodeShortURLs.pm ... it
> appears that, if you are running in a per-user setup (i.e., running
> spamd as root such that it does a setuid <user> when invoked from
> spamc, and/or allowing individual users to run spamassassin), then
> the short-URL cache used by DSU must be world-writable (or, more
> correctly, writable by all users invoking spamd/SA), else the DSU
> rules fail.  This is because DSU is trying to write to the cache
> file; if it appears read-only to spamd/SA, the HAS_SHORT_URL rule
> fails, which halts DSU operation.
>       Unfortunately the error is completely silent unless running
> in debug mode, and since very few people operate spamd that way (or
> even SA, in normal usage), the only way one would notice this is
> because the rule fails to fire when it should.  Sysadmins who
> normally use spamd as root, but check their installation via manually
> invoking SA as root, could potentially miss this.

Or probably more commonly when running  the spamassassin perl script as
an ordinary user for test purposes.  

> I filed an issue at DSU's github:
> https://github.com/smfreegard/DecodeShortURLs/issues/6
> The workaround for now, if running per-user, is to make the DB
> world-writable.  The ultimate solution would be to fail gracefully
> (ignore failure to write; treat failure to read as "not found";
> perform appropriate lookups even if not writable), 

Actually it does get cached results from the DB and does fall back to
doing its own lookup. The debug is a little misleading because it tries
either to update the timestamp or create a new entry before it even logs
the result, and that's where it fails.

I don't really understand the database interface, but if the two
relevant  execute commands are placed in eval blocks it seems to work.
cache_add() does use an eval block for setting-up the SQL, but the
execute is outside the block.

Reply via email to