Re: [LSF/MM TOPIC] fs-verity: file system-level integrity protection

[Theodore Ts'o <tytso@mit.edu>]

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.