On Mon, Oct 19, 2015 at 8:45 PM, Austin S Hemmelgarn <ahferroin7@xxxxxxxxx> wrote: > On 2015-10-19 13:33, Andreas Gruenbacher wrote: >> Please spare me with all that nonsense. Compared to mount options, >> filesystem feature flags in this case simplify things (you don't have >> to specify whether a filesystem contains POSIX ACLs or richacls), and >> they prevent administrator errors: when a filesystem mounts, it is >> safe to use; when it doesn't, it is not. That's all there is to it. > > You're ignoring what I'm actually saying. I've said absolutely nothing > about needing to use mount options at all, and I'm not arguing against using > filesystem feature flags, I'm arguing for using them sensibly in a way that > does not present a false sense of security. We could be on a multi-user system, and the user mounting the filesystem may not be the only user on the system. When a filesystem can be mounted read-only, it should be safe to use read-only. It is not safe in general to use such a filesystem read-only, so an incompatible feature flag which prevents such unsafe mounting is more approporiate than a read-only incompatible feature flag. Mounting a filesystem read-only doesn't mean that the filesystem is being recovered, it is perfectly legal to mount a filesystem read-only for other reasons. I don't want to give people using read-only filesystems the false sense that everything is okay. > Making it an incompatible flag will likely cause headaches for some > legitimate users, Indeed. It will also make it less likely for users to accidentally shoot themselves in the foot. If someone knows better, they can clear the feature flag. When recovering a broken system that contains richacl filesystems, you really want to have richacl support in the rescue system as well. Otherwise, you won't be able to fsck those filesystems. > and at most delay competent hackers by a few seconds to a > few minutes, and script kiddies by a few hours, and is really no better than > security by obscurity (and from a purely logistical standpoint, that's _all_ > it is) in that it actively tries to hide the fact that someone having read > access to the storage the filesystem is on can bypass the ACL's. > > To reiterate, if someone can call mount() on a filesystem, and mount() does > not return -EPERM, then even if mount() returns a different error, they > still have the ability to completely bypass all permissions and ACL's in > that filesystem, because they have the ability to read the entire filesystem > directly. > > The _only_ way to properly protect against people bypassing the ACL's is to > use full disk encryption and lock down root access on the system, and even > that can't completely prevent it from happening. That's all completely beside the point. I'm not talking about preventing attacks at all, just basic administrative workflows. Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
