| Message ID | f914d2c4-b3eb-f52b-6010-0447ac874fb5@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Zero umask when unpacking sstate packages | expand |
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
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
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
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
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")