Re: [OE-core] [PATCH] sstate.bbclass: apply proper umask when fetching from SSTATE_MIRROR

[Rasmus Villemoes <ravi@prevas.dk>]

On Wed, Jun 25 2025, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:

> On Tue, 2025-06-17 at 09:41 +0200, Rasmus Villemoes wrote:
>> On Sun, Jun 15 2025, "Richard Purdie via lists.openembedded.org" <richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
>> 
>> > On Fri, 2025-06-06 at 11:39 +0200, Rasmus Villemoes wrote:
>> > > From: Rasmus Villemoes <ravi@prevas.dk>
>> > > 
>> > > Currently, files and directories created under ${SSTATE_DIR} when
>> > > fetching from an sstate mirror are not created with group write,
>> > > unlike when the sstate artifacts are generated locally. That's
>> > > inconsistent, and problematic when the local sstate dir is shared
>> > > among multiple users.
>> > > 
>> > > Wrap the fetching in a bb.utils.umask() context manager, and for simplicity
>> > > move the mkdir of SSTATE_DIR inside that.
>> > > 
>> 
>> > I appreciate this sounds crazy but this is causing some kind of
>> > regression being reported in our automated testing. Specifically,
>> > running:
>> > 
>> > oe-selftest -r sstatetests.SStateCreation -j 1
>> > 
>> > fails for me locally with this applied, as it does here in CI:
>> > 
>> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/1767
>> > 
>> > Worryingly, if I run:
>> > 
>> > oeselftest -r sstatetests.SStateCreation.test_sstate_creation_distro_specific_pass -j 1
>> > 
>> > i.e. a specific failing test, that fails even without the patch
>> > applied, and it shouldn't so there is something odd going on here even
>> > before the patch.
>> > 
>> > We're going to have to get to the bottom of this before I can merge the
>> > patch.
>> 
>
> I finally got to the bottom of the issues. NATIVELSBSTRING handling was
> causing weirdness when running the tests which was than masking other
> problems. Once I fixed that, I could unravel the problem with badperms,
> which was just broken as you mentioned. In the end I cleaned up the
> umask handling there using bb.utils.umask and combined some of the test
> cases for clarity too. I've sent a couple of patches.
>
> This should mean your patch can now merge as it is correct IMO and the
> tests were just broken/breaking.

Thanks for taking the time to work through this. I was hoping the needed
fixups were small enough (or localized enough) that my patch, along with
those fixups, could be eligible for walnascar. What's your take on that?

I got into this because we currently have to set BB_DEFAULT_UMASK =
"002" to get the sstate dir perms right on our shared build
infrastructure, but it turns out that that cure is worse than the
disease as I wrote here:
https://lore.kernel.org/openembedded-core/87wm9r1wcx.fsf@prevas.dk/

Thanks,
Rasmus