Re: [PATCH v3 23/26] xfs: Filter XFS_ATTR_PARENT for getfattr

[Allison Henderson <allison.henderson@oracle.com>]

On Tue, 2022-09-27 at 11:32 -0700, Darrick J. Wong wrote:
> On Mon, Sep 26, 2022 at 09:49:42PM +0000, Allison Henderson wrote:
> > On Fri, 2022-09-23 at 14:45 -0700, Darrick J. Wong wrote:
> > > On Wed, Sep 21, 2022 at 10:44:55PM -0700,
> > > allison.henderson@oracle.com wrote:
> > > > From: Allison Henderson <allison.henderson@oracle.com>
> > > > 
> > > > Parent pointers returned to the get_fattr tool cause errors
> > > > since
> > > > the tool cannot parse parent pointers.  Fix this by filtering
> > > > parent
> > > > parent pointers from xfs_attr_list.
> > > 
> > > Yes!!  Parent pointers should /never/ be accessible by the
> > > standard
> > > VFS
> > > xattr syscalls, nor should the XFS ATTR_MULTI calls handle them.
> > > 
> > > Changes to parent pointers are performed via separate syscalls
> > > (link/unlink/mknod/creat/etc), and I see you've created a
> > > separate
> > > parent pointer ioctl later on for userspace to retrieve them.  I
> > > think
> > > this is the correct access model.
> > > 
> > > To check that assertion -- getxattr/setxattr/removexattr (and the
> > > ATTRMULTI
> > > equivalents) are prevented from accessing parent pointers
> > > directly
> > > because you'd have to be able to set XFS_ATTR_PARENT in
> > > xfs_da_args.attr_filter, right?
> > Well, you set XFS_IOC_ATTR_PARENT which later translates to
> > XFS_ATTR_PARENT.  I do that later in the set, but I see you've
> > already
> > commented on it
> 
> <nod>
> 
> > > 
> > > And for the VFS to get/set/remove a parent pointer, XFS would
> > > have to
> > > provide a struct xattr_handler with ->flags = XFS_ATTR_PARENT,
> > > which
> > > XFS
> > > will never do, right?
> > Well, this set does not plan to make any vfs modifications at least
> > :-)
> > 
> > > 
> > > And for ATTR_MULTI to touch a parent pointer, xfs_attr_filter
> > > (and
> > > the
> > > ioctl api) would have to learn about XFS_ATTR_PARENT, which XFS
> > > will
> > > also never do, right?
> > I think we do have to publish that XFS_ATTR_PARENT exists, but I
> > don't
> > think we have to implement the XFS_IOC_ATTR_PARENT translation
> 
> Agreed.  The fewer symbols that end up in xfs_fs.h the better,
> because
> anything we publish in there becomes a part of the userspace ABI and
> has
> to be supported "forever".
> 
> > > If the answers to these three questions are all yes then you're
> > > 95%
> > > of
> > > the way to an RVB, except...
> > > 
> > > > Signed-off-by: Allison Henderson <allison.henderson@oracle.com>
> > > > ---
> > > >  fs/xfs/libxfs/xfs_da_format.h |  3 +++
> > > >  fs/xfs/xfs_attr_list.c        | 47
> > > > +++++++++++++++++++++++++++----
> > > > ----
> > > >  2 files changed, 39 insertions(+), 11 deletions(-)
> > > > 
> > > > diff --git a/fs/xfs/libxfs/xfs_da_format.h
> > > > b/fs/xfs/libxfs/xfs_da_format.h
> > > > index b02b67f1999e..e9c323fab6f3 100644
> > > > --- a/fs/xfs/libxfs/xfs_da_format.h
> > > > +++ b/fs/xfs/libxfs/xfs_da_format.h
> > > > @@ -697,6 +697,9 @@ struct xfs_attr3_leafblock {
> > > >  #define XFS_ATTR_INCOMPLETE    (1u << XFS_ATTR_INCOMPLETE_BIT)
> > > >  #define XFS_ATTR_NSP_ONDISK_MASK \
> > > >                         (XFS_ATTR_ROOT | XFS_ATTR_SECURE |
> > > > XFS_ATTR_PARENT)
> > > > +#define XFS_ATTR_ALL \
> > > > +       (XFS_ATTR_LOCAL_BIT | XFS_ATTR_ROOT | XFS_ATTR_SECURE |
> > > > \
> > > > +        XFS_ATTR_PARENT | XFS_ATTR_INCOMPLETE_BIT)
> > > >  
> > > >  /*
> > > >   * Alignment for namelist and valuelist entries (since they
> > > > are
> > > > mixed
> > > > diff --git a/fs/xfs/xfs_attr_list.c b/fs/xfs/xfs_attr_list.c
> > > > index a51f7f13a352..13de597c4996 100644
> > > > --- a/fs/xfs/xfs_attr_list.c
> > > > +++ b/fs/xfs/xfs_attr_list.c
> > > > @@ -39,6 +39,23 @@ xfs_attr_shortform_compare(const void *a,
> > > > const
> > > > void *b)
> > > >         }
> > > >  }
> > > >  
> > > > +/*
> > > > + * Returns true or false if the parent attribute should be
> > > > listed
> > > > + */
> > > > +static bool
> > > > +xfs_attr_filter_parent(
> > > > +       struct xfs_attr_list_context    *context,
> > > > +       int                             flags)
> > > > +{
> > > > +       if (!(flags & XFS_ATTR_PARENT))
> > > > +               return true;
> > > > +
> > > > +       if (context->attr_filter & XFS_ATTR_PARENT)
> > > > +               return true;
> > > > +
> > > > +       return false;
> > > 
> > > ...wouldn't it suffice to do:
> > > 
> > > static inline bool
> > > xfs_attr_filter_listent(
> > >         struct xfs_attr_list_context    *context,
> > >         int                             flags)
> > > {
> > >         return context->attr_filter != (flags &
> > > XFS_ATTR_NSP_ONDISK_MASK);
> > > }
> > Almost.... XFS_ATTR_NSP_ONDISK_MASK includes XFS_ATTR_PARENT, so
> > here
> > we'd want XFS_ATTR_NSP_ONDISK_MASK & ~XFS_ATTR_PARENT
> > 
> > Also, XFS_ATTR_NSP_ONDISK_MASK doesnt include XFS_ATTR_LOCAL which
> > was
> > previously allowable
> > 
> > Hmm, how bout just:
> >         return context->attr_filter != flags & (XFS_ATTR_ROOT |
> > XFS_ATTR_SECURE | XFS_ATTR_LOCAL)
> > 
> > I think that preserves the existing behavior
> 
> It does, but I think it'll cause conflicts with future online fsck
> code.
> 
> (Let me check my understanding of the xfs_attr_list callers first:
> 
> There are /three/ namespaces, but only two of them have defined flag
> bits.  "root.*" and "secure.*" have XFS_ATTR_{ROOT,SECURE}, but
> "user.*"
> is recorded by the absence of any XFS_ATTR_ flag.  IOWs, attr_filter
> isn't a bit mask of all the namespaces that the caller wants; it's a
> cookie value to coordinate between the xfs_attr_list caller and the
> supplied putent function.
> 
> vfs_listxattr doesn't allow userspace to specify an xattr namespace,
> so
> it returns xattrs from user.*, root.*, and secure.*. 
> xfs_vn_listxattr
> doesn't set attr_filter, and xfs_xattr_put_listent doesn't check.
> 
> XFS_IOC_ATTRLIST_BY_HANDLE, on the other hand, requires userspace to
> specify which namespace they want to list.  That's why it's the one
> caller that sets context.attr_filter, and xfs_ioc_attr_put_listent
> does
> a comparison to filter attributes from other namespaces.
> 
> The xattr scrubber calls xfs_attr_list_ilocked to walk every xattr
> attached to the file.  For each call to ->put_listent, it uses the
> built-in hash information to look up the attr name provided to
> confirm
> that hashed lookups also work.  For /this/ usecase, we want
> xfs_attr_list_* to return all xattrs because we need to check all
> xattr
> namespaces.  Hence it doesn't set context.attr_filter, and
> xchk_xattr_listent doesn't check it either.
> 
> ...right?)
> 
> ((Come to think of it -- shouldn't the ifork and attr leaf block
> verifiers check that each attr entry struct have at most one of the
> namespace bits set?))
> 
> After the addition of parent pointers, xfs_xattr_put_listent needs to
> filter out (flags & XFS_ATTR_PARENT) cases. 
> XFS_IOC_ATTRLIST_BY_HANDLE
> won't need any changes if we drop the XFS_IOC_ATTR_PARENT flag, since
> there won't be any way for XFS_ATTR_PARENT to be set in attr_filter.
> The xattr scrubber still needs to walk every xattr to perform a
> complete
> scan.  Hence it will still not touch context.attr_filter, nor will it
> want any filtering to be applied at all.
> 
> For the forthcoming totally-doesn't-exist-yet parent pointer online
> fsck
> code, I'd sorta like to reuse that function to walk only the parent
> pointers.  I'm not 100% sure I will end up doing that -- the
> cursoring
> code would be useful if I have to use a live inode scan to do the
> checking and repair, but OTOH it's a little annoying to deal with the
> warts of the xfs_attr_list_context.  But in theory, I'd have
> xchk_parent_listent or whatever the function ends up being named
> ignore
> anything that wasn't XFS_ATTR_PARENT.  This mechanism also does not
> want
> the xfs_attr_list_* functions to perform any filtering.
> 
> In terms of APIs, xfs_attr_filter_parent doesn't really make a lot of
> sense -- if you set context.attr_filter = XFS_ATTR_PARENT, you'll get
> all the xattrs (including the non-parent ones), but if you set any
> other
> value (e.g. XFS_ATTR_SECURE), you'll get all the non-parent xattrs,
> including the root.* and user.* attrs.  The ->put_listent function
> still
> has to do its own filtering.  Right?
> 
> What if xfs_xattr_put_listent exited early if (flags &
> XFS_ATTR_PARENT)
> and we never define a XFS_IOC_ATTR_ROOT?  Won't that suffice to
> prevent
> the userspace xattr APIs from ever returning a parent pointer by
> accident?
> 
> Looking ahead to the GETPARENTS code, I think the filtering code in
> xfs_ioc_attr_put_listent would work for returning only the parent
> pointers, right?  Since it does set context.attr_filter to
> XFS_ATTR_PARENT on its own?  And you wouldn't need any of the other
> changes here?
Ok, I tried this out and it seems to work, so I will add this in the
next revision.  Thanks for the reviews!

Allison
> 
> --D
> 
> > > 
> > > like how xfs_ioc_attr_put_listent does?  And then...
> > > 
> > > > +}
> > > > +
> > > >  #define XFS_ISRESET_CURSOR(cursor) \
> > > >         (!((cursor)->initted) && !((cursor)->hashval) && \
> > > >          !((cursor)->blkno) && !((cursor)->offset))
> > > > @@ -90,11 +107,12 @@ xfs_attr_shortform_list(
> > > >                                                               
> > > > sfe-
> > > > > namelen,
> > > >                                                               
> > > > sfe-
> > > > > flags)))
> > > >                                 return -EFSCORRUPTED;
> > > > -                       context->put_listent(context,
> > > > -                                            sfe->flags,
> > > > -                                            sfe->nameval,
> > > > -                                            (int)sfe->namelen,
> > > > -                                            (int)sfe-
> > > > >valuelen);
> > > > +                       if (xfs_attr_filter_parent(context,
> > > > sfe-
> > > > > flags))
> > > > +                               context->put_listent(context,
> > > > +                                                    sfe-
> > > > >flags,
> > > > +                                                    sfe-
> > > > >nameval,
> > > > +                                                    (int)sfe-
> > > > > namelen,
> > > > +                                                    (int)sfe-
> > > > > valuelen);
> > > >                         /*
> > > >                          * Either search callback finished
> > > > early or
> > > >                          * didn't fit it all in the buffer
> > > > after
> > > > all.
> > > > @@ -185,11 +203,12 @@ xfs_attr_shortform_list(
> > > >                         error = -EFSCORRUPTED;
> > > >                         goto out;
> > > >                 }
> > > > -               context->put_listent(context,
> > > > -                                    sbp->flags,
> > > > -                                    sbp->name,
> > > > -                                    sbp->namelen,
> > > > -                                    sbp->valuelen);
> > > > +               if (xfs_attr_filter_parent(context, sbp-
> > > > >flags))
> > > > +                       context->put_listent(context,
> > > > +                                            sbp->flags,
> > > > +                                            sbp->name,
> > > > +                                            sbp->namelen,
> > > > +                                            sbp->valuelen);
> > > >                 if (context->seen_enough)
> > > >                         break;
> > > >                 cursor->offset++;
> > > > @@ -474,8 +493,10 @@ xfs_attr3_leaf_list_int(
> > > >                                    !xfs_attr_namecheck(mp,
> > > > name,
> > > > namelen,
> > > >                                                        entry-
> > > > > flags)))
> > > >                         return -EFSCORRUPTED;
> > > > -               context->put_listent(context, entry->flags,
> > > > +               if (xfs_attr_filter_parent(context, entry-
> > > > >flags))
> > > > +                       context->put_listent(context, entry-
> > > > >flags,
> > > >                                               name, namelen,
> > > > valuelen);
> > > > +
> > > >                 if (context->seen_enough)
> > > >                         break;
> > > >                 cursor->offset++;
> > > > @@ -539,6 +560,10 @@ xfs_attr_list(
> > > >         if (xfs_is_shutdown(dp->i_mount))
> > > >                 return -EIO;
> > > >  
> > > > +       if (context->attr_filter == 0)
> > > > +               context->attr_filter =
> > > > +                       XFS_ATTR_ALL & ~XFS_ATTR_PARENT;
> > > 
> > > ...I think this is unnecessary since none of the callers can
> > > actually
> > > set XFS_ATTR_PARENT in the first place, right?
> > > 
> > The caller can stuff any bit in there they want, but until now it
> > didn't matter because context->attr_filter was unused (getfattr
> > appears
> > to just leave it as 0).  So the existing behavior was that
> > requesting
> > nothing resulted in everything.  Now we're flipping that (at least
> > internally).
> > 
> > If we use the filter logic above, this would need to turn into
> > context->attr_filter = (XFS_ATTR_ROOT | XFS_ATTR_SECURE |
> > XFS_ATTR_LOCAL)
> > 
> > > --D
> > > 
> > > > +
> > > >         lock_mode = xfs_ilock_attr_map_shared(dp);
> > > >         error = xfs_attr_list_ilocked(context);
> > > >         xfs_iunlock(dp, lock_mode);
> > > > -- 
> > > > 2.25.1
> > > > 
> >