On 2015-10-16 13:41, Andreas Gruenbacher wrote:
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.On Fri, Oct 16, 2015 at 7:31 PM, Austin S Hemmelgarn <ahferroin7@xxxxxxxxx> 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.
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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
