It took long enough to remove these options - I finally ran into it in 6.4.0 (still was working in the previous kernel I was using: 5.14). If I had not remembered that they were going to be removed someday, I would have never figured out how to fix the updated system so it would boot properly (no error messages that I could see mentioned acls nor user_xattr options).
Also, the man page for ext(2,3,4) still insists these options are valid.
The man page lists itself as:
E2fsprogs version 1.47.0 February 2023 EXT4(5)
The options themselves should be recognized (but ignored) so they are not a serious error (they should report a WARNING when used - both noacl and acl options should report a WARNING that they are ignored, and that acl is assumed).
This should be the case with ANY option that is no longer supported (warning, but ignored).
Additionally, mount should report their state when you query the mount options (on any FS that always supports acl and user_xattr),
particularly when one uses: mount -v
Besides helping the person who is trying to turn them off notice that they are still on, it will also let people who expect them to be on verify that they are on.
Personally, I still would want the option of mounting a local filesystem noacl (which I can effectively do with ZFS).
And I have seen many posts online of others who want that option. But I understand if it is to complicated to give admins a way to turn it on and off.
quote from the ext4 man page:
Mount options for ext4
The ext4 file system is an advanced level of the ext3 file system which incorporates scala-
bility and reliability enhancements for supporting large file system.
The options journal_dev, journal_path, norecovery, noload, data, commit, orlov, oldalloc,
[no]user_xattr, [no]acl, bsddf, minixdf, debug, errors, data_err, grpid, bsdgroups, nogrpid,
sysvgroups, resgid, resuid, sb, quota, noquota, nouid32, grpquota, usrquota, usrjquota, gr-
pjquota, and jqfmt are backwardly compatible with ext3 or ext2.
Note about paulfm@xxxxxxxxxx: paulfm@xxxxxxxxxx went away as a valid email address, several years ago.
please contact me at the email this was sent from (if there are any old questions that bounced, you can send them to me).
On 2013-11-18 12:31 PM, Eric Sandeen wrote:
On 11/18/13, 8:26 AM, Paul FM wrote:
Yes - I need noacl and nouser_xattr
How about documenting your intent to remove them in the man pages.
acl support and user_xattr support need to be off on the / and /usr
filesystems to simplify security. Actually I want a way to turn off
ALL extended attribute support on any filesystem. How about noxattr
(which would turn off ALL extended attribute support including acls).
I also use nosuid on filesystems that shouldn't have any suid files.
This is to follow the security principal - "If you aren't using it
and don't need it - turn it off".
FWIW, it still can be disabled at build time via CONFIG_EXT3_FS_POSIX_ACL
But if you are using a distro kernel that turns that on, I see
your point about noacl.
However, I'm not sure how nouser_xattr comes into the argument?
xattrs by themselves are just metadata; they don't impact security
control unless they are a special kind of xattrs (i.e. acls).
Thanks,
-Eric
The simple Posix/Unix permissions are more than enough security
control in almost every situation I have run into (only wish I could
use them in Windows).
Having worked extensively with ACLS on Windows (and some older Main
Frame OSes) - I note that ACL's add a level of complexity to security
that actually makes for less security. I see the need to support
them in Unix/Linux - but they should be OFF unless someone
specifically wants to use them (at least don't make them hard to turn
off).
Just try auditing the security of a windows filesystem if you don't
think ACL's add extreme complexity (I gave up - I just forcibily set
all the ACL's myself by script using the unix Owner,Group,Other
concepts as a model to simplify what I am setting).
--
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s). The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM Info: http://paulfm.com/~paulfm/
--------------------------------------------------------
