On Fri, Jan 26, 2018, at 10:29 AM, Theodore Ts'o wrote: > The problem is not the userspace API, it's the bike-shedding over all > of the different ways we could *do* immutability, all of which would > require separate bits in the on-disk representation of the inode. You > can have any combination of: > > * Immutable data > * Immutable metadata > * Immutable xattrs Everyone here wants immutable data (*all* of the data I hope), and security.* xattr namespace at least. The user. xattr namespace...eh. If it's simpler to seal *all* xattr namespaces that seems sane to me. (Who would want immutable xattrs but *not* immutable data?) > * Immutable links_counts (don't allow hard links / don't allow deletes) > * Immutable timestamps So this part is definitely where ostree and dpkg/rpm diverge for example. rpm -V treats different link counts as an error, where of course the entire way ostree works is using hardlinks. We also canonicalize all timestamps to 0 and would ideally have those immutable, though it's not like much really breaks if they change. > * etc. > * Who is allowed to set the immutable bit? ostree (unlike e.g. docker which uses overlayfs) works just great as non-root and I really like that for the build system use case. We currently have a terrible FUSE filesystem that implements the "immutable hardlinked files": https://github.com/ostreedev/ostree/tree/master/src/rofiles-fuse Which obviously like a lot of FUSE filesystems is buggy. (Of course I know there's patches for unprivileged overlayfs in progress) Also as I mentioned git could use it. > * Is the immutable bit allowed to be cleared? If so, by who? No, that breaks the whole point. (Did anyone ask for that?) > We picked a particular set of combinations for the current immutable > bit, and they clearly aren't to your liking; so you are essentially > trying to propose another bit, with a different set of the above > combinations. The problem is this doesn't scale. I am not familiar with the LSF/MM process so forgive me if it's obvious; but are the details of your proposal posted? I don't see it in the initial mail, and the conversation that followed didn't fully clarify it. > Given that this *is* such a fringe use case, I'm not so sure about that. The other example I gave was `visudo`. If you think about /etc, almost *every* file in there should have "object semantics" too. And of course most of my ~/. config files. > I wonder if a better way > of satisfying your wishlist is to have a mount option which changes > how the immutable bit is enforced; essentially from reading the > previous mail thread, you want to (a) allow non-root users to set the > immutable bit, (b) you want to disable the immutable bit from being > cleared, and (c) allow immutable files to be deleted and hard linked. > Yes? All of that, plus: - At least security. xattr namespace sealed, or all of them if no one cares about the user. one being dynamic (I'm honestly not sure how much uptake that xattr has in userspace) - This also applies to symlinks (mostly for xattrs) - Probably make the timestamps immutable too That's the ostree semantics. Now this is just my opinion of course but I think the future of classical dpkg/rpm is to live on top of overlayfs in containers ;) Since overlayfs already does copyup, it doesn't matter too much if we make the "content immutable" bit allow hardlinks does it? Mutating the filesystem underneath an overlayfs is currently undefined anyways. (Oh actually of course overlayfs roots is a whole other use case for this but that's what James was getting at) > P.S. The reason why it would be tricky to set the immutable bit on a > directory Directories are a whole other topic. Is that covered at all in fs-verity? Though honestly big picture at some point down the line we're likely to just make our /sysroot mount read-only or possibly even hidden inside a privileged mount namespace, and remove it from the default mount namespace. See https://github.com/ostreedev/ostree/issues/1265 And that ameliorates a *lot* of the "accidental damage" issues for host systems. It doesn't help flatpak (which fill a similar role as APKs). It also doesn't get us out of the FUSE requirement for unprivileged build systems. > P.P.S. You could also implement your own custom LSM which enforces > your particular use case. That might be a better way to go at least > in the short-term, especially since we now have stable LSM support. And you're thinking that say the LSM would key off an xattr or something? I suppose actually we could change the SELinux policy to deny even "unconfined_t" from writing to `usr_t` etc. Hmm, I may look at that. I'd have to make it an ostree-system-based specific policy tweak as it'd almost certainly break dpkg/rpm+SELinux systems. But let's have the list of use cases handy: - host root filesystem - overlayfs lower layers - ostree cases (buildroots, flatpak, host system) - dpkg/rpm (mostly differs from ostree in not wanting hardlinks?) - git (loose objects + packfiles) - Lots of /etc OK actually I just read the mail chain and I think I understand; you're proposing the tree covers the inode basically as is, and that's why it wouldn't allow hardlinks? Can we reuse the Unix permission bits or something to say that files that are u+w but have the verity bit set allow hardlinking, and then teach the code to just ignore the hardlink count?
