https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6173
Summary: auto_whitelist_file_mode interpreted as decimal for
lock files
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: All
OS/Version: Linux
Status: NEW
Severity: minor
Priority: P4
Component: Libraries
AssignedTo: [email protected]
ReportedBy: [email protected]
Created an attachment (id=4506)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4506)
Patch to fix wrong interpretation of auto_whitelist_file_mode and ignore user
umask.
Lock files for the file 'auto-whitelist' are created with weird permissions
such as '-r------w- .... auto-whitelist.lock.mail.gn.apc.org.8889'.
The auto_whitelist_file_mode is interpreted correctly in octal for creating the
auto-whitelist file through DB_File, although it does now apply the user-set
umask (see below). Inconsistently, however, the interpretation as octal does
not seem to work for lockfile creation.
At first, I thought it might be related to me using bash chmod style '660'
without the leading 0, but that turns out to be irrelevant, and the problem is
still present with '0660'. It looks like safe_lock() is passing the mode to
umask as if it were in decimal (660), and I think this is a regression from the
patch for bug 4936. The line reads:
$mode = oct $mode if $mode =~ /^0/; # accept number or string
In fact, the type of $mode should be numeric (decimal) as specified in the
Conf.
Since bug 4936 was patched, the other issue has been remarked on at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412224 and also here in bug
5498. This is that there is now no longer control over all the r/w bits. E.g.
on a system with umask 022, it may still be useful to have
auto_whitelist_file_mode 0660, so the database can be shared between amavis and
other processes running as different users. The Debian bug puts it this way:
"auto_whitelist_file_mode uses an inappropriate umask (possibly the
user's umask, which by default is 022). This is in contradiction to the
documentation in man Mail::SpamAssassin::Plugin::AWL.
"The documentation claims that I should have the x bits set in
auo_whitelist_file_mode, since it might be used to create directories as
well; AWL is supposed to mask the x bits out when creating files instead
of directories. However, what AWL actually does now is apply a umask of
022 regardless. For example, I had auto_whitelist_file_mode set to 0770,
but my ~/.spamassassin/auto-whitelist files get created with mode 0750
instead of the 0660 expected."
Bug 4936 supposedly corrects the following issues: "SA ignores user-set umask
(naughty), sets umask(0) at one point (very naughty) and sets
umask(auto_whitelist_file_mode ^ 0770) (WTF is that XOR doing out there?)." In
fact the patch also overrides the user-set umask in the Locker modules, so this
isn't really an issue; the final XORing with 0700 before the patch was indeed a
bit weird.
Here's a patch that I think fixes both these problems. Perhaps the default
conf setting should be returned to 0700 as well: I don't know what database
modules if any create directories, but it would concord better with the POD
documentation.
--
Configure bugmail:
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
