On 2015-10-16 13:41, Andreas Gruenbacher wrote:

On Fri, Oct 16, 2015 at 7:31 PM, Austin S Hemmelgarn
[off-list ref] wrote:

quoted

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.

If it's not safe WRT data integrity, then the design needs to be 
reworked, as that directly implies that isn't safe for even every day 
usage on a writable filesystem.

If it's not safe WRT the ACL's being honored, then that really isn't 
something we should be worrying about.  POSIX ACL's have this issue, as 
does mounting a filesystem on any system with a different 
/etc/{passwd,shadow,group,gshadow} than the one that wrote the 
permissions to the FS in the first place, and as such this is the type 
of thing any sensible system administrator will already expect to be 
dangerous, which means in turn that they will only do it if there is no 
other choice.

Trying to rely on making this an incompat feature to 'enforce' the ACL's 
is inherently flawed for two very specific reasons:
1. If the person theoretically trying to attack the system has write 
access to the disk, they can flip the feature bit and get access anyway 
(seriously, this takes maybe ten minutes of looking at the source code, 
some simple math and a hex editor).
2. If the disk is read-only (or even if it's writable), they can just 
forgo mounting the filesystem entirely and use any of a number of 
existing tools to pull the data directly off of the disk.

As I said in a previous discussion about this, the three most likely 
reasons for someone mounting a filesystem with this feature on a kernel 
that doesn't support it are:
1. They've booted into a recovery environment (eg SystemRescueCD) to 
attempt to recover data from the system itself (this usage implies 
access to the hardware, and therefore the ACL's are inherently useless 
for protecting the data anyway).
2. They've pulled the disk and hooked it up to a different system to 
recover data from it (again, this implies access to the hardware, and 
ACL's are inherently useless for protecting from this).
3. They're trying to bisect a kernel bug introduced at around the same 
time that richacls went in (which means again they have hardware access 
and ACL's are useless).
All that making this an incompat feature will do is make things harder 
for these legitimate use cases, for any competent attacker it will only 
be a minor inconvenience.