Zero umask when unpacking sstate packages

Zero umask when unpacking sstate packages

[Jacob Kroon]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

Hi,

I often see this diff churn in my buildistory for shadow-native (and
similar issues with icedtea7-native from meta-java):

-drwxr-xr-x -          -                  40 ./var/spool/mail
+drwxrwxr-x -          -                  40 ./var/spool/mail

One can reproduce it with:

# bitbake -c cleansstate shadow-native && \
  bitbake shadow-native && \
  bitbake -c clean shadow-native && \
  bitbake shadow-native

I see that the sstate package contains the correct permissions for
'mail', 775. So it would seem to me that it is the unpacking from sstate
that strips the group write permission.

Testing with the attached patch and the problem goes away.

Is something like this the correct solution ?

Jacob

[-- Attachment #2: 0001-sstate.bbclass-Zero-umask-when-unpacking-from-sstate.patch --]
[-- Type: text/x-patch, Size: 843 bytes --]

From dcebf2977cb6bdc5198ab13272cf358c9ecd6b32 Mon Sep 17 00:00:00 2001
From: Jacob Kroon <jacob.kroon@gmail.com>
Date: Thu, 13 Jan 2022 16:31:47 +0100
Subject: [PATCH] sstate.bbclass: Zero umask when unpacking from sstate cache

Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
---
 meta/classes/sstate.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 645377fdd8..0c32387f43 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -793,7 +793,9 @@ pstaging_fetch[vardepsexclude] += "SRCPV"
 
 def sstate_setscene(d):
     shared_state = sstate_state_fromvars(d)
+    omask = os.umask(0)
     accelerate = sstate_installpkg(shared_state, d)
+    os.umask(omask)
     if not accelerate:
         bb.fatal("No suitable staging package found")
 

Re: [OE-core] Zero umask when unpacking sstate packages

[Richard Purdie]

On Thu, 2022-01-13 at 16:44 +0100, Jacob Kroon wrote:
> Hi,
> 
> I often see this diff churn in my buildistory for shadow-native (and
> similar issues with icedtea7-native from meta-java):
> 
> -drwxr-xr-x -          -                  40 ./var/spool/mail
> +drwxrwxr-x -          -                  40 ./var/spool/mail
> 
> One can reproduce it with:
> 
> # bitbake -c cleansstate shadow-native && \
>   bitbake shadow-native && \
>   bitbake -c clean shadow-native && \
>   bitbake shadow-native
> 
> I see that the sstate package contains the correct permissions for
> 'mail', 775. So it would seem to me that it is the unpacking from sstate
> that strips the group write permission.
> 
> Testing with the attached patch and the problem goes away.
> 
> Is something like this the correct solution ?

Is this with master?

I'm wondering if your code has:

https://git.yoctoproject.org/poky/commit/?id=c4ecf7c1122380cdbc74fe692aa91756dc5bdf6b

applied?

Cheers,

Richard

Re: [OE-core] Zero umask when unpacking sstate packages

[Jacob Kroon]

On 1/13/22 23:07, Richard Purdie wrote:
> On Thu, 2022-01-13 at 16:44 +0100, Jacob Kroon wrote:
>> Hi,
>>
>> I often see this diff churn in my buildistory for shadow-native (and
>> similar issues with icedtea7-native from meta-java):
>>
>> -drwxr-xr-x -          -                  40 ./var/spool/mail
>> +drwxrwxr-x -          -                  40 ./var/spool/mail
>>
>> One can reproduce it with:
>>
>> # bitbake -c cleansstate shadow-native && \
>>   bitbake shadow-native && \
>>   bitbake -c clean shadow-native && \
>>   bitbake shadow-native
>>
>> I see that the sstate package contains the correct permissions for
>> 'mail', 775. So it would seem to me that it is the unpacking from sstate
>> that strips the group write permission.
>>
>> Testing with the attached patch and the problem goes away.
>>
>> Is something like this the correct solution ?
> 
> Is this with master?
> 
> I'm wondering if your code has:
> 
> https://git.yoctoproject.org/poky/commit/?id=c4ecf7c1122380cdbc74fe692aa91756dc5bdf6b
> 
> applied?
> 

Yes, this is with master branches of bitbake/openembedded-core as of
right now.

So yes, I do have that patch applied.

Jacob

Re: [OE-core] Zero umask when unpacking sstate packages

[Richard Purdie]

On Thu, 2022-01-13 at 23:11 +0100, Jacob Kroon wrote:
> On 1/13/22 23:07, Richard Purdie wrote:
> > On Thu, 2022-01-13 at 16:44 +0100, Jacob Kroon wrote:
> > > Hi,
> > > 
> > > I often see this diff churn in my buildistory for shadow-native (and
> > > similar issues with icedtea7-native from meta-java):
> > > 
> > > -drwxr-xr-x -          -                  40 ./var/spool/mail
> > > +drwxrwxr-x -          -                  40 ./var/spool/mail
> > > 
> > > One can reproduce it with:
> > > 
> > > # bitbake -c cleansstate shadow-native && \
> > >   bitbake shadow-native && \
> > >   bitbake -c clean shadow-native && \
> > >   bitbake shadow-native
> > > 
> > > I see that the sstate package contains the correct permissions for
> > > 'mail', 775. So it would seem to me that it is the unpacking from sstate
> > > that strips the group write permission.
> > > 
> > > Testing with the attached patch and the problem goes away.
> > > 
> > > Is something like this the correct solution ?
> > 
> > Is this with master?
> > 
> > I'm wondering if your code has:
> > 
> > https://git.yoctoproject.org/poky/commit/?id=c4ecf7c1122380cdbc74fe692aa91756dc5bdf6b
> > 
> > applied?
> > 
> 
> Yes, this is with master branches of bitbake/openembedded-core as of
> right now.
> 
> So yes, I do have that patch applied.

I guess that whilst the default task umask is 022, some chmod operations may be
run to change permissions that don't match the umask. These are correctly
captured by the sstate archive but not preserved by tar at extraction.

I wonder if the correct fix is to all -p to the tar unpack command in
sstate.bbclass?

In many cases it would execute under pseudo so there wouldn't be this issue but
a native populate_sysroot wouldn't be under pseudo do we'd only see that here...

Cheers,

Richard

Re: [OE-core] Zero umask when unpacking sstate packages

[Jacob Kroon]

On 1/13/22 23:20, Richard Purdie wrote:
> On Thu, 2022-01-13 at 23:11 +0100, Jacob Kroon wrote:
>> On 1/13/22 23:07, Richard Purdie wrote:
>>> On Thu, 2022-01-13 at 16:44 +0100, Jacob Kroon wrote:
>>>> Hi,
>>>>
>>>> I often see this diff churn in my buildistory for shadow-native (and
>>>> similar issues with icedtea7-native from meta-java):
>>>>
>>>> -drwxr-xr-x -          -                  40 ./var/spool/mail
>>>> +drwxrwxr-x -          -                  40 ./var/spool/mail
>>>>
>>>> One can reproduce it with:
>>>>
>>>> # bitbake -c cleansstate shadow-native && \
>>>>   bitbake shadow-native && \
>>>>   bitbake -c clean shadow-native && \
>>>>   bitbake shadow-native
>>>>
>>>> I see that the sstate package contains the correct permissions for
>>>> 'mail', 775. So it would seem to me that it is the unpacking from sstate
>>>> that strips the group write permission.
>>>>
>>>> Testing with the attached patch and the problem goes away.
>>>>
>>>> Is something like this the correct solution ?
>>>
>>> Is this with master?
>>>
>>> I'm wondering if your code has:
>>>
>>> https://git.yoctoproject.org/poky/commit/?id=c4ecf7c1122380cdbc74fe692aa91756dc5bdf6b
>>>
>>> applied?
>>>
>>
>> Yes, this is with master branches of bitbake/openembedded-core as of
>> right now.
>>
>> So yes, I do have that patch applied.
> 
> I guess that whilst the default task umask is 022, some chmod operations may be
> run to change permissions that don't match the umask. These are correctly
> captured by the sstate archive but not preserved by tar at extraction.
> 
> I wonder if the correct fix is to all -p to the tar unpack command in
> sstate.bbclass?
> 
> In many cases it would execute under pseudo so there wouldn't be this issue but
> a native populate_sysroot wouldn't be under pseudo do we'd only see that here...
> 

Thanks Richard, passing -p in sstate_unpack_package() also fixes the
issue. If it is run as root under pseudo for target packages, then the
-p is implicit according to the tar docs, which would explain why the
issue isn't seen there.

I'll send a new patch.

Jacob