On Sat, Oct 17, 2015 at 02:22:25AM +0200, Andreas Gruenbacher wrote: > > Suppose we mounted a file system with richacl's on a kernel that > > didn't understand it, and we write to from that non-richacl kernel. > > What's the worse that could happen? > > Two things are likely to happen. First, richacls will not be enforced; > this can cause fewer or more permissions to be granted. Second, when > files are created, permission inheritance will not take place, so when > the filesystem is later used by a richacl aware kernel, permissions > will be inconsistent. > > > So why would this result in incompatible file systems? > > The filesystems will not become incompatible in an e2fsck sense, but > it will generally become unsafe to expose in a multi-user environment. > So the question is what the different kinds of feature flags are > supposed to protect from exactly. Hmm. So my original conception of the ext2/3/4 feature flags was more about incompatibility from a e2fsck sense --- what I would call in a metadata self-consistency sense. I don't think we ever thought about the failure of the inheritance to be an "inconsistency". Perhaps it would be considered such from a semantic point of view, but it's not something we could ever check using e2fsck, since it's possible that the user had intentionally removed the richacl from a file, even though all of the other files in the directory have a richacl which matches the default directory inheritance acl. So the downside of using a feature flag (and it doesn't matter whether it's an incompat or a read-only flag) is that it requires new versions of e2fsprogs in order to be able to support the file system --- when it really doesn't matter from an e2fsprogs support perspective. One way of dealing with this is would be use a new mount option to enable richacls (e.g., "richacl"), which older kernels would fail to recognize and would thus fail the mount. This works since the most likely failure case is if the user boots into an older kernel. This doesn't protect against the case where someone is using richacls on a USB stick, and moves it over to another system --- but that seems like a use case that's not very likely. It also doesn't help against someone using an old rescue cd-rom, but in that case, it's not clear that it's hugely problematic, either -- someone using rescue media has physical access to the machine, so access controls are generally not a major concern, and they are also not likely to be making wholesale changes to the file system where acl inheritance is going to be a primary concern, either. This is basically how we handled the POSIX acl situation for ext4 --- we just required a mount option to enable it, originally and eventually we defaulted the option to always on once it was highly unlikely someone was going to be trying to install, say, a 2.6 kernel on an enterprise userspace --- which was not likely to work at all. What do you think? If we really want to burn a feature flag, I'd probably use a RO_INCOMPAT flag rather than an INCOMPAT flag, on the theory that read-only mounts are much more often used for system administration. But it might be using a mount option is a better way to go here. Cheers, - Ted P.S. I can imagine adding new KERNEL_INCOMPAT and KERNEL_ROCOMPAT feature set flags in the superblock which are ignored by e2fsprogs, but only used by the kernel. This might be helpful in the future, but it won't help us now, since old kernels won't be checking them. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
