Re: [PATCH 3/5] ovl: make redirect/metacopy rejection consistent

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 11, 2025 at 1:34 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Tue, 11 Feb 2025 at 13:01, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> > Really? I looked at the next patch before suggesting this
> > I did not see the breakage. Can you point it out?
>
> When lookup "falls off" of the normal lower layers while in metacopy
> mode with an absolute redirect, then it jumps to the data-only layers.
> The above suggestion imitates this falling off when it's really a
> permission problem, which would result in weird behavior, AFAICS.
>

Yes, I see it now.
I don't have a better idea at the moment.

> > BTW, this patch is adding consistency to following upperredirect
> > but the case of upperredirect and uppermetacopy read from
> > index still does not check metacopy/redirect config.
>
> True.  Also that case should probably "loop back" to verifying that
> the redirection indeed results in the same origin as pointed to by the
> index, right?
>

It sounds very complicated. Is that even possible?
Do we always know the path of the upper alias?
IIRC, the absolute redirect path in upper is not necessary
the absolute path where the origin is found.
e.g. if there are middle layer redirects of parents.

> > Looking closer at ovl_maybe_validate_verity(), it's actually
> > worse - if you create an upper without metacopy above
> > a lower with metacopy, ovl_validate_verity() will only check
> > the metacopy xattr on metapath, which is the uppermost
> > and find no md5digest, so create an upper above a metacopy
> > lower is a way to avert verity check.
>
> I need to dig into how verity is supposed to work as I'm not seeing it
> clearly yet...
>

The short version - for lazy data lookup we store the lowerdata
redirect absolute path in the ovl entry stack, but we do not store
the verity digest, we just store OVL_HAS_DIGEST inode flag if there
is a digest in metacopy xattr.

If we store the digest from lookup time in ovl entry stack, your changes
may be easier.

> > So I think lookup code needs to disallow finding metacopy
> > in middle layer and need to enforce that also when upper is found
> > via index.
>
> That's the hard link case.  I.e. with metacopy=on,index=on it's
> possible that one link is metacopyied up, and the other one is then
> found through the index.  Metacopy *should* work in this case, no?
>

Right. So I guess we only need to disallow uppermetacopy from
index when metacoy=off.

Thanks,
Amir.





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux