On Fri, Dec 21, 2018 at 9:58 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Thu, Dec 20, 2018 at 05:01:58PM -0500, Theodore Y. Ts'o wrote: > > That's simply not true. Number one, fsverity is not mandatory for all > > file systems to implement. If XFS doesn't want to implement fscrypt > > or fsverity, it doesn't have to. Number two, we're not *making* any > > changes to the kernel code; nothing in mm/filemap.c, et. al. So > > saying that we are making changes that are impacted by /everyone/ just > > doesn't make any sense. > > Ted, I think you know yourself this isn't true. Whenever we added > useful interface to one of the major file systems we had other pick > it up, and that is a good thing because the last thing we need is > fragmentation of interfaces. And even if that wasn't the case I don't > think we should take short cuts, because even if an interface was just > for a file system or two it still needs to be properly desgined. > > There is no reason to rush interfacs in, because everytime we have done > that it has turned out to be a very bad idea in retrospective. Speaking of interfaces, one thing that needs IMHO more thought is the user facing interface. Not only in the fsverity case, in all cases. Linux has currently many different ways to implement and check (cryptographic)-integrity. Just to name a few, fsverity, UBIFS' auth feature, BTRFS csum, EVM/IMA, dm-integrity, dm-verity, ... At least for filesystems it would be good to have a common interface to query the integrity status of a file. So far we have mixture of different return codes (EPERM, EUCLEAN, EINVAL), audit events plus cryptic kernel logs. In UBIFS we return EPERM in case of an auth failure, we followed EVM/IMA. fsverity goes the EUCLEAN route, just like BTRFS for check sum failures. Before everything is set in stone, let's try to consolidate at least this. Along with that, what about the statx() interface? We have already STATX_ATTR_ENCRYPTED, why no STATX_ATTR_AUTHENTICATED? -- Thanks, //richard
