rechunker: Support recursively associating a directory with a component

[ckyrouac]

Spawned from this comment

---

Unrelated to this specific line but just looking at this...I think the 95% case here is that people will want this to operate recursively, right?

A nice way to do this is to make it supported to set user.component on a directory to mean applying to all of its children or so. And here debate whether that's including directory children i.e. recursive or not. If it is recursive we'd probably need an opt-out (setting the xattr to the empty string?)

Hmm and now that I look/think about this slightly more I guess the challenge is that the whole codebase leading up to this is object-based and isn't operating on the directory tree.

But in theory we could (while traversing to build up the object set) add this mapping if we detect the parent directory has it set.

[ckyrouac]

I think this may be necessary in order to support cleanly adding directories with symlinks (especially broken symlinks) to a layer. e.g. when trying to recursively add containers storage (/usr/lib/containers), a bunch of symlinks can't be added. Using the elevated namespace trusted.component allows setting the fattr on the symlink but it still fails if the symlink is broken. This only seems to be an issue on the container build (due to the fs type?). I'm able to set the trusted.component fattr on broken symlinks on my local btrfs filesystem. Anyways, it seems like implementing this issue will be required to support adding containers storage to a specific layer, unless I'm missing something?

[cgwalters]

I think we just need to use the -h option to setfattr

[ckyrouac]

All my tests were with -h set

[cgwalters]

Sorry I should have read your message in more detail. Investigating a bit yes this is quite complicated.

A tricky thing with xattrs in general is that the different namespaces user. vs security. etc. can have different permissions assigned in the kernel.

Oh wait...wait...this is triggering a dim memory for me now...and with that memory as a tip yes here's the code:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/xattr.c#n142

A followon ugly thing here is that the availability of user. vs trusted e.g. are a function of e.g. podman rootless vs rootful.

In a rootful podman build, I think we can safely use trusted.component say for everything. But that won't work rootless where we can only use user. and not on symlinks.

(rootless podman here might bifurcate on "fuse-overlayfs" vs overlayfs...in theory there should be no restrictions for fuse-overlayfs, it should be allowing us to write whatever because it's just lookaside metadata, ah wait this may relate to whether statoverride is enabled https://github.com/containers/fuse-overlayfs/blob/2772fa30c72dfdeed3cdf43c6a918019a717cee0/main.c#L545 )

Anyways umm...yeah this is going to be messy.

So the recursive thing on directories should Just Work for cases that can do it.

The messy problem here is cases where there's a shared directory (exactly like /usr/bin) that we want to split up based on components.

Now an interesting observation here is that symlinks are just metadata, so in theory...assuming they don't change often we could just dump them in their own layer (or in a layer with other metadata). Though that would cause change amplification if one did change often (e.g. has a version number embedded)

The other thing we could do is parse a TOML/whatever mapping file from inside the image, but yeah less elegant.

Or...a different idea, we have user.component.link=foo=bar as xattrs on directories that declare which component the symlink goes to. That might scale OK...

[cgwalters]

We had a live chat re this

Hmm and now that I look/think about this slightly more I guess the challenge is that the whole codebase leading up to this is object-based and isn't operating on the directory tree.

I just put up containers/composefs-rs#167

It wouldn't be too hard to add a helper version of this which eagerly parses a whole ostree commit into the in-memory data structure, then there'd be way less tedium in reading it.
LMK if you want to go that route