[PATCH v11 21/48] ext4: Add richacl feature flag

[Austin S Hemmelgarn]

On 2015-10-19 11:34, Andreas Gruenbacher wrote:
> On Mon, Oct 19, 2015 at 3:16 PM, Austin S Hemmelgarn
> <ahferroin7 at gmail.com> wrote:
>> On 2015-10-16 13:41, Andreas Gruenbacher wrote:
>>>
>>> On Fri, Oct 16, 2015 at 7:31 PM, Austin S Hemmelgarn
>>> <ahferroin7 at gmail.com> wrote:
>>>>
>>>> I would like to re-iterate, on both XFS and ext4, I _really_ think this
>>>> should be a ro_compat flag, and not an incompat one.  If a person has the
>>>> ability to mount the FS (even if it's a read-only mount), then they by
>>>> definition have read access to the file or partition that the filesystem
>>>> is contained in, which means that any ACL's stored on the filesystem are
>>>> functionally irrelevant,
>>>
>>> It is unfortunately not safe to make such a file system accessible to
>>> other users, so the feature is not strictly read-only compatible.
>>>
>> OK, seeing as I wasn't particularly clear as to why I object to this in my
>> other e-mail, let's try this again.
>>
>> Can you please explain exactly why it isn't safe to make such a filesystem
>> accessible to other users?
>
> See here: http://www.spinics.net/lists/linux-ext4/msg49541.html
OK, so to clarify, this isn't 'safe' because:
1. The richacls that exist on the filesystem won't be enforced.
2. Newly created files will have no ACL's set.

It is worth noting that these are also issues with any kind of access 
control mechanism.  Using your logic, all LSM's need to set separate 
incompat feature flags in filesystems they are being used on, as should 
POSIX ACLs, and for that matter so should Samba in many circumstances, 
and any NFS system not using idmapping or synchronized/centralized user 
databases.  Now, if the SELinux (or SMACK, or TOMOYO) people had taken 
this approach, then I might be inclined to not complain (at least not to 
you, I'd be complaining to them about this rather poor design choice), 
but that is not the case, because (I assume) they realized that all this 
provides is a false sense of security.

Issue 1, as I have said before, is functionally irrelevant for anyone 
who actually knows what they are doing; all you need for ext* is one of 
the myriad of programs for un-deleting files on such a filesystem (such 
as ext4magic or extundelete, and good luck convincing them to not allow 
being used when this flag is set), for BTRFS you just need the regular 
filesystem administration utilities ('btrfs restore' works wonders, and 
that one will _never_ honor any kind of permissions, because it's for 
disaster recovery), and while I don't know of any way to do this with 
XFS, that is only because I don't use XFS myself and have not had the 
need to provide tech support for anyone who does.  If somebody 
absolutely _needs_ a guarantee that the acls will be enforced, they need 
to be using whole disk encryption, not just acls, and even that can't 
provide such a guarantee.

As for issue 2, that can be solved by making it a read-only compatible 
flag, which is what I was suggesting be done in the first place.  The 
only situation I can think of that this would cause an issue for is if 
the filesystem was not cleanly unmounted, and the log-replay doesn't set 
the ACL's, but mounting an uncleanly unmounted filesystem that has 
richacls on a kernel without support should fall into one of the 
following 2 cases more than 99% of the time:
1. The system crashed hard, and the regular kernel is un-bootable for 
some reason, in this case you're at the point of disaster recovery, 
should not be exposing _anything_ to a multi-user environment, and 
probably care a lot more about being able to get the system running 
again than about not accidentally creating a file with a missing ACL.
2. The filesystem was maliciously stolen in some way (either the 
hardware was acquired, or more likely, someone got an image of a still 
mounted filesystem), in which case all of my statements above regarding 
issue 1 apply.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3019 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20151019/586810ae/attachment-0001.p7s>