Re: [meta-virtualization] possible regression with: image-oci-unmoci: preserve file modes

> Bruce Ashfield via lists.yoctoproject.org <[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)

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
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#9664): https://lists.yoctoproject.org/g/meta-virtualization/message/9664
> Mute This Topic: https://lists.yoctoproject.org/mt/118351110/10013339
> Group Owner: [email protected]
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [[email protected]]
> -=-=-=-=-=-=-=-=-=-=-=-
>