Message-ID: <2291ff18-9aaf-4b2a-023c-cf3abcef5a70@gmail.com>
Date: Mon, 1 Apr 2024 11:54:13 -0500
From: Paul Markfort <paulfm.mn@...il.com>
To: linux-ext4@...r.kernel.org
Subject: Re: noacl and nouser_xattr


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@...umn.edu:  paulfm@...umn.edu 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/
--------------------------------------------------------

Powered by blists - more mailing lists