https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6994
Bug ID: 6994
Summary: SpamAssassin's perm test is invalid; disable & let
user manage security?
Product: Spamassassin
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: Building & Packaging
Assignee: [email protected]
Reporter: [email protected]
I found a similar bug in File::Slurp.
The text I put in describing the problem there was:
-------------------------------------------------------------------------
t/perms.t sets umask to 027
writes a file and checks that file's mode is
0640.
This is not guaranteed to be true on file systems
with ACL's.
It is best illustrated by setting a default ACL on the direct in which you are
creating the test file. That sets the ACL on any newly created file. Give
'other' any access other than none (like 'r-x' instead of '---').
Then any file created will give "other" read access for non-executables. The
defaults established by the file systems override process defaults like umask.
Ishtar:> umask 027
Ishtar:> touch zzz
> > ll zzz
-rw-rw-r--+ 1 0 Jan 22 21:01 zzz
---why?---
> > lsacl zzz
[u::rw-,u:law:rwx,g::rwx,g:lawgroup:rwx,m::rw-,o::r--] zzz
(which it inherited from the directory) -- which specifies its own ACL and a
default acl for created files.
---------------
SA does a similar test :
sub checkmode {
my $fname = shift;
if (!-f $fname) { return 1; }
my ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size) = stat $fname;
return (($mode & 0777) == 0644);
}
ok checkmode "log/user_state/awl"; # DB_File
ok checkmode "log/user_state/awl.dir"; # SDBM
ok checkmode "log/user_state/awl.pag"; # SDBM
ok checkmode "log/user_state/awl.mutex";
================
The above can't be tested for on a system that has ACL's -- which may or may
not be settable by the user (usually should be, but may not be on some systems
with stronger security).
---------------------
At the very least, this breaks the building of this package on systems that
have have default directory ACL's in use -- as they are propagated to created
subdirectories as well as given-by-default to newly created files.
--
You are receiving this mail because:
You are the assignee for the bug.
