On Wed, 2018-12-19 at 22:12 +0200, Amir Goldstein wrote: > On Wed, Dec 19, 2018 at 9:34 PM James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Wed, 2018-12-19 at 13:15 -0500, Mimi Zohar wrote: > > > On Wed, 2018-12-19 at 08:56 -0800, James Bottomley wrote: > > > > On Wed, 2018-12-19 at 10:39 -0500, Mimi Zohar wrote: > > > > > Confirmed, in linux-4.18.y d_backing_inode returns the real > > > > > i_ino, but newer kernels do not. > > > > > > > > Just so we're clear, this isn't an issue with > > > > d_backing_inode(), which hasn't changed since its introduction > > > > in 2015 and which always returns dentry->d_inode (it was > > > > originally a helper for unionfs which got merged even though > > > > unionfs didn't, which makes it and the comment about > > > > upper/lower totally misleading). The problem is that overlayfs > > > > has changed the inode it places into d_inode. > > > > > > > > > This is a problem for EVM as the i_ino is included in the > > > > > HMAC calculation. > > > > > > > > Isn't the solution always to use portable signatures for > > > > containers? It's problematic to include inode and generation > > > > with an overlay because if you change the metadata it gets > > > > copied up => new inode number and generation on the upper > > > > filesystem but if we were always using the underlying inode > > > > number and generation, the signature would then be wrong on the > > > > copied up file. > > > > > > > > At base, most container images are sets of tar files, which are > > > > not inode number preserving anyway, so even if we find a > > > > convoluted way to fix the above, the EVM signature has to be > > > > portable because otherwise its always wrong for container > > > > images. > > > > > > Ignaz's use case was mutable files, not immutable files with file > > > signatures. > > > > The word "mutable" is problematic in terms of overlays. Only the > > upper layer is mutable, so if your EVM signed file is anywhere > > other than in the top layer it's technically immutable. What you > > get when you mutate it is a copy up. the VFS guarantee is that > > inode numbers are stable only for the current mount and may change > > on a remount. Most disk backed filesystems have inode numbers > > encoded in their on disk inodes, which is why they have far more > > stability than the simple VFS requirement, but some filesystems > > can't have long term stable inode numbers. We recognise this > > problem in EVM with so called "portable signatures" that don't > > include the inode number and generation. > > > > I'm interested in discussing two points > > > > 1. Can we actually come up with semantics where the EVM > > signature is > > always valid for overlays? > > What you are looking for is a persistent and stable identifier for > the inode object. Such a property already exists for filesystems that > support NFS file handles. Well, that's really what I'm asking. I know if we want container rather than content then filehandle is definitely the way to go for the same reasons that NFS transitioned away from inode numbers. However, I'm asking the question what value is there in hashing a container identifier instead of the real file contents? James
