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

[Colin Walters <walters@verbum.org>]

On Fri, Jan 26, 2018, at 11:49 AM, James Bottomley wrote:
> On Fri, 2018-01-26 at 11:40 -0500, Colin Walters wrote:
> > 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),
> 
> No, no, I don't.   In the world today most linux distributions from
> which we produce containers do have the annoying property of writing
> stuff where they shouldn't (mostly into /etc). 

Sorry, I meant that no one was asking for *partially* immutable single files,
like how one can F_SETLK byte ranges today.  Now that I think about it
though that's kind of what log files like the systemd journal want (i.e. O_APPEND like)
but honestly people who care about that kind of stuff tend to send log messages remotely
anyways and I personally care a whole lot more about binaries (basically
ideally fs-verity covers at least everything that can gain CAP_SYS_ADMIN,
including e.g. supporting local signing of installed RPMs/host extensions,
and notably if one has a Docker container or whatever that is configured
to gain CAP_SYS_ADMIN on start, or equivalent).