On Fri, Jan 26, 2018 at 02:58:39AM -0500, Colin Walters wrote: > Hi, it's me again! I was summoned by this mention of > read-only files. You may recall our previous conversation: > https://www.spinics.net/lists/linux-fsdevel/msg75086.html > (I also cleverly tried to work it in to a tangentially related DAX > discussion in https://marc.info/?l=linux-fsdevel&m=150152316817001&w=2 ) > > So given this proposal will require read-only files, can we do > the interface bikeshedding soon around what the userspace API > will look like, and have it be orthogonal to (but a prerequisite for) fs-verity? 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 * Immutable links_counts (don't allow hard links / don't allow deletes) * Immutable timestamps * etc. * Who is allowed to set the immutable bit? * Is the immutable bit allowed to be cleared? If so, by who? So it's not userspace API, it's the feature explosion --- for something which I consider to be a fringe use case. 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. Given that this *is* such a fringe use case, 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? I'd much rather keep this entirely orthogonal to the fs-verity proposal, because we could easily end up rat holing all of the different ways *different* applications might want to interpret immutability. - Ted P.S. The reason why it would be tricky to set the immutable bit on a directory is because of your wish for (b) and (c) as you requested in [2] is if you make a directory immutable, and you can't clear the immutable bit --- then it becomes impossible to delete a non-empty directory, since we don't have rm -rf as a system call. So if the kernel prohibits a directory from being changed, then we can't delete the files in the directory --- and thus we can't empty the directory to delete it. Allowing a non-root user to be able to permanently make files completely undeletable is... a non-starter. [2] https://www.spinics.net/lists/linux-fsdevel/msg75087.html 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.
