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

[Rasmus Villemoes <ravi@prevas.dk>]

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

> On Thu, 2025-06-26 at 08:51 +0200, Rasmus Villemoes wrote:
>> On Wed, Jun 25 2025, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>> 
>> > 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?
>
> A quick poll of a few developers on the review call as we discussed
> these changes suggested it would be a candidate to backport.

Great.

>> 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/
>
> I have been meaning to look at that a bit. We haven't really supported
> changing the overall default umask as the potential for unintended
> changes is significant.

Yes, I realized :) But since the sstate dirs/files were not (always)
created with the permissions we wanted, I thought that BB_DEFAULT_UMASK
was the proper knob. Only when that turned out to have unwanted side
effects did I dig deeper and found that the sstate code already tries to
create files/dirs with group write, but with the mirror case overlooked
(which explained the odd mix of permissions we observed).

We also share our DL_DIR, and the fetch code doesn't seem to ensure 
group write is allowed - perhaps we just need to set do_fetch[umask],
but is it intended that DL_DIR should be sharable? The problem occurs
when one user would build a newer git-based recipe and thus would need
write access to DL_DIR/git2/foo-bar.git/ and that dir had originally
been created by some other user.

> It could probably be made to work but someone would need to put a lot
> of development work in.

Well, we'll be happy to just get rid of our non-default
BB_DEFAULT_UMASK.

But it might be an idea to ensure that do_rootfs[umask] and
do_image[umask] are 022, regardless of the global default umask, or at
least have some warning in place if they aren't. I haven't really tested
setting those; it's possible that the BB_DEFAULT_UMASK setting ends up
polluting stuff before it gets into the rootfs.

Rasmus