https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6994
--- Comment #5 from linda w <[email protected]> --- > Agreed. But I think administrators using ACLs know this as a general > rule. **** You don't need to be an admin to use an ACL.**** >> The point I'm trying to make is that it isn't just about installing >> -- that can be easily worked around -- but that you are providing >> that test as a guarantee of some security feature -- and that >> guarantee CAN'T be guaranteed on any file system that supports ACL's. > > But the test fails, correct? Hence saying the functionality isn't > appropriate on that system. If the test PASSED, I would agree. ---- I am rebuilding it from the CPAN sources, but haven't done this for years -- I use the SuSE rpms. This is the first notice I've had that SA testing was insecure on any system using ACL's... (not that it affects me that much -- as I'm the only user on my system; but for anyone relying on that feature, they need to know that it isn't secure on any modern system (since nearly all support user-ACL's). All of SuSe's systems can have ACL's, but their build systems wouldn't be likely to use them so none of their users would would know how insecure their systems are or that ACL's are a problem. With sendmail, ACL's are not a problem. -- they detect acl's. So it is perfectly possible for projects that want to ensure file mode security to do so, even with ACL's (I think ssh does as well). Most users would just assume the projects got it right. With suse, they wouldn't build or test with ACL's, since they only use a bare-bones, minimal environment these days -- that is torn down and cleaned between each product being built. They don't even *test* if a fully installed SuSE system (installed with devel packages) will be able to build their rpm's. In many cases it can't because the normal package "configure" looks for what devel packages are installed and will build differently if it finds different packages installed from what Suse had on their build systems. > What is your recommended fix because if a system administrator is > using ACLs, --- *** System admins are not needed to use ACL's.*** They are on by default in most kernels and usable, by default on older file systems where they've always existed (like XFS). > I'm assuming they know the impact it has on umasks and permission > bits? ---- I didn't -- why? (besides me being clueless in many situations and one person can't know everything, ;^)), -- but because I don't use UMASKs to enforce security. If I want something set a certain way, I use chmod most often. I.e. If a sysadmin is security conscious, they are likely not going to be relying on 'umask' to set perms. They'll likely use chmod/groups and ACL's. I've been using ACL's for several years. XFS has always supported them and supports them by default. It's not like Extfs where it was added-on, later, and has to be explicitly enabled. As a "parallel example", do you rely on your "GID" to set the group on files? If you do, I'm sure you know that if a parent directory has the setGID bit set, that such would override your normal GID, but wuoldn't AFAIK, prevent them from changing the group, explicitly, after creation. The reason the test fails is that it relies on an insecure mechanism to set file permissions (umask). UMASK should be thought of more as a convenience than anything else -- since filesystem and OS defaults can override it. If specific permissions are wanted, they need to be explicitly set. Example: tmp> lsacl . [u::rwx,g::rwx,o::r-x] . tmp> chacl -d u::rwx,g::rwx,o::r-x . > umask 777 tmp> touch a tmp> ll a -rw-rw-r-- 1 0 Jan 23 22:30 a tmp> chmod 000 a tmp> ll a ---------- 1 0 Jan 23 22:30 a tmp> lsacl a [u::---,g::---,o::---] a You can't rely on UMASK to set permissions on a file. You can use chmod -- and that will override "directory defaults". As for thinking admins would know about this? Some might, but as I mentioned, no admins are needed for ACL's to be used. -- You are receiving this mail because: You are the assignee for the bug.
