On Tue, Aug 22, 2023 at 5:03 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Tue, 22 Aug 2023 at 16:36, Alexander Larsson <alexl@xxxxxxxxxx> wrote:
> >
> > On Tue, Aug 22, 2023 at 4:25 PM Alexander Larsson <alexl@xxxxxxxxxx> wrote:
> > >
> > > On Tue, Aug 22, 2023 at 3:56 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> > > >
> > > > On Tue, 22 Aug 2023 at 15:22, Alexander Larsson <alexl@xxxxxxxxxx> wrote:
>
> > > > > The only way I see to implement that conversion is to call getxattr()
> > > > > on every DT_REG file during readdir(), and while a single getxattr()
> > > > > on lookup is fine, I don't think that is.
> > > > >
> > > > > Any other ideas?
> > > >
> > > > Not messing with d_type seems a good idea. How about a random
> > > > unreserved chardev?
> > >
> > > Only the whiteout one (0,0) can be created by non-root users.
> >
> > I was thinking of (ab)using DT_SOCK or DT_FIFO, but turns out you
> > can't store xattrs on such files.
>
> The "user." xattr namespace is for regular files and directories only.
> And "trusted." is privileged, obviously.
Ah, so for the trusted case using a DT_FIFO with a xattr could work.
> At this point I'm not sure what are your requirements. Does creating
> escaped whiteout need to be unprivleged? If so, how did the
> "user.overlay.nowhiteout" work?
I guess I didn't test the userxattrs version of whiteouts. Need to add
that to the xfstest changes.
So, it seems that it just isn't possible to support nesting whiteouts
with userxattrs in an unprivileged way.
Lets just focus on privileged use then. My personal primary goals lean
towards privileged use anyway, because composefs uses loopback erofs
mounts which require privileges anyway.
It feels sort of dangerous using a "real" char device node. What if
some driver happens to use that major/minor. Then we would not allow
using that device node in overlayfs, and it may cause a program to
unexpectedly open the device and talk to the driver. Otoh, not having
to mess with d_type is nice.
Alternatively we could use DT_FIFO files with a
trusted.overlay.whiteout. Then we can handle whiteouts for DT_FIFO in
the readdir code like how regular whiteouts work (i.e. something like
the maybe_whiteout list). On the assumption that both fifos and
whiteouts are not super common, this should probably work pretty well.
Opinions?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx
