On Tue, Mar 17, 2026 at 5:40 AM <[email protected]> wrote:
> > > Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield= > [email protected]> hat am 16.03.2026 21:21 CET geschrieben: > > > > > > > > > > > > On Mon, Mar 16, 2026 at 2:42 PM Patrick Vogelaar via > lists.yoctoproject.org (http://lists.yoctoproject.org) < > patrick.vogelaar.dev (http://patrick.vogelaar.dev)= > [email protected]> wrote: > > > Hi all, > > > > > > [0] caused a regression on my site. I am installing a recipe into the > container that sets ACLs with setfacl in pkg_postinst. To my understanding > those xattr were not preserved before anyways so wouldn't it be better to > change it to: > > > > > Hmm. The -a has been around for over a year in master, so we need to > > dig into this more. > > > > My recollection and quick check is that -a should be copying the xattrs > > from our source to the umoci layer structure. > > > > The bbclass operates on the fully assembled image, so anything you've > > put in place for ACLs, etc, should be preserved. > > > > Rather than dropping -a, I'd extend it with --preserve=xattr if we are > missing > > something in a binutils -> filesystem -> or something else combination. > > > > If you had specific examples, I could comment further. > > > That is what is done in the recipe: > > pkg_postinst:${PN}() { > chmod 040 $D${sysconfdir}/example.conf > setfacl -m g:example-users:r $D${sysconfdir}/example.conf > } > > and this is the error I am getting: > > cp: preserving permissions for '<path>/example.conf': Invalid argument > > I dug a bit deeper and I was wrong that it is related to the ACLs, the 040 > mode is the problem. > > My best guess so far is that do_image_oci runs under pseudo but > ${WORKDIR}/deploy- is added in PSEUDO_IGNORE_PATHS. Since IMGDEPLOYDIR is > ${WORKDIR}/deploy-${PN}-image-complete, the entire umoci bundle directory > is outside pseudo coverage. > > This means cp -r -a in do_image_oci: > * read: the source rootfs through pseudo (works fine, pseudo fakes root > ownership) > * write: to the deploy dir without pseudo (runs as the real unprivileged > build user) > > Anything is possible, but that shouldn't be the case. All do_image_* tasks (including do_image_oci) are automatically marked fakeroot by image.bbclass during the image type setup loop. So the cp -a, rsync, and find operations in IMAGE_CMD:oci all run under pseudo, which means file ownership, permissions, device nodes, and special files are racked correctly through the copy into the umoci staging area. Here's what I think (and I'm almost sure), is happening Those ACLs were never copying over reliably, or at least by the design of the system (and I don't mean meta-virt, I mean OE and pseudo) they shouldn't have been. a) setfacl in the postinst runs during do_rootfs (also under pseudo). It calls setxattr() for system.posix_acl_access. Depending on the underlying tmp/ filesystem, the ACL may get written to the real filesystem bypassing pseudo's database (pseudo doesn't intercept system.* xattrs consistently) But maybe it is that your tmp/ is holding them as it is the right filesystem (I'm guessing there). b) During do_image_oci, cp -a (--preserve=all) reads the source file, sees it has a POSIX ACL (from the real filesystem), and tries to setxattr(system.posix_acl_access) on the destination. Pseudo intercepts that call and returns EINVAL because it doesn't know how to handle it. BUT, here's the kicker. The ACLs wouldn't survive umoci repack into the OCI tar layer anyway — umoci uses Go's archive/tar which doesn't preserve POSIX ACLs. You'll see that in the mult-layer OCI image work in master. Before this patch, cp -r didn't try to preserve xattrs/ACLs at all, so the possibly broken setfacl under pseudo was silently ignored. Now with -a, cp attempts to read and replicate the ACL xattrs, hits pseudo's EINVAL on setxattr(system.posix_acl_access), and fails visibly. My best suggestion is that something needs to be done on the target at runtime when the container starts (e.g., in an entrypoint script or a systemd unit), not in a build-time postinst. That's the only path I can think of where ACLs will actually be effective on the running filesystem. Bruce > This means that cp -a tries to preserve mode 040 and the unprivileged > build user cannot remove their own read permission on files they own. > > Does this make sense? I am not too familiar with the permissions handling. > > Patrick > > > > > Bruce > > > > > > > > > cp -r --preserve=mode,timestamps,links ${IMAGE_ROOTFS}/* > $image_bundle_name/rootfs > > > > > > Could also be that I am doing something wrong in my recipe when > setting the ACLs. > > > > > > [0] > https://git.yoctoproject.org/meta-virtualization/commit/?h=scarthgap > > > > > > Best Regards > > > Patrick > > > > > > > > > > > > > > > > > > -- > > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9666): https://lists.yoctoproject.org/g/meta-virtualization/message/9666 Mute This Topic: https://lists.yoctoproject.org/mt/118351110/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
