[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    [OE-core] non uniform directories permissions in sstate-cache
From:       Andrea Galbusera <gizero () gmail ! com>
Date:       2017-09-30 15:51:48
Message-ID: CAC+thW2LM0aNJ+Ro8mq6GX1gYB8K83tro8v-kYxfa+oLoJYj-g () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Recent posts on both Yocto's ML and here mentioned this issue, but I prefer
to post in a new thread, since it's possible that the main focus of those
thread (sharing sstate-cache between multiple users) might somewhat have
shadowed what IMHO seems indeed an issue with directories permissions in
sstate-cache.

What I observed on at least three different build hosts is quite simple:
the permissions directories in sstate-cache/ are not uniform. Most of them
are 775, but some are 755. This happens with fresh builds (all by the same
user) and can be observed on master and morty branches for sure (not
verified with pyro).

Anyone else seeing this? It might have been unnoticed, or you might have an
explanation to state this is normal, but I'd be very surprised if you told
me I'm alone in seeing this. Between the hosts that showed this behaviour I
have Ubuntu 16.04 boxes (either baremetal or Virtualbox VMs) and the
crops/poky-container running on OSX native docker implementation.

After noticing this, I got a look at sstate.bbclass, which I believe is the
code responsible for actually creating those hierarchies. The following
snippet seems to be the place where, regardless of the process' umask,
bitbake should ensure sstate-cache subdirs are created with 775 permissions
(by changing the process' umask to 002). Am I missing other places where
this is handled indeed?

   omask = os.umask(0o002)
   if omask != 0o002:
      bb.note("Using umask 0o002 (not %0o) for sstate packaging" % omask)
   sstate_package(shared_state, d)
   os.umask(omask)

Now, I'd don't feel confident enough with the code to push my investigation
further, than I'm writing this to hopefully have someone more experienced
looking at it and help figuring out what's going on.

Any thought? Should I file it as a bug?

[Attachment #5 (text/html)]

<div dir="ltr">Recent posts on both Yocto&#39;s ML and here mentioned this issue, but \
I prefer to post in a new thread, since it&#39;s possible that the main focus of \
those thread (sharing sstate-cache between multiple users) might somewhat have \
shadowed what IMHO seems indeed an issue with directories permissions in \
sstate-cache.<div><br></div><div>What I observed on at least three different build \
hosts is quite simple: the permissions directories in sstate-cache/ are not uniform. \
Most of them are 775, but some are 755. This happens with fresh builds (all by the \
same user) and can be observed on master and morty branches for sure (not verified \
with pyro).</div><div><br></div><div>Anyone else seeing this? It might have been \
unnoticed, or you might have an explanation to state this is normal, but I&#39;d be \
very surprised if you told me I&#39;m alone in seeing this. Between the hosts that \
showed this behaviour I have Ubuntu 16.04 boxes (either baremetal or Virtualbox VMs) \
and the crops/poky-container running on OSX native docker \
implementation.</div><div><br></div><div>After noticing this, I got a look at \
sstate.bbclass, which I believe is the code responsible for actually creating those \
hierarchies. The following snippet seems to be the place where, regardless of the \
process&#39; umask, bitbake should ensure sstate-cache subdirs are created with 775 \
permissions (by changing the process&#39; umask to 002). Am I missing other places \
where this is handled indeed?</div><div><br></div><div><div><div>     omask = \
os.umask(0o002)</div><div>     if omask != 0o002:</div><div>         \
bb.note(&quot;Using umask 0o002 (not %0o) for sstate packaging&quot; % \
omask)</div><div>     sstate_package(shared_state, d)</div><div>     \
os.umask(omask)</div></div></div><div><br></div><div>Now, I&#39;d don&#39;t feel \
confident enough with the code to push my investigation further, than I&#39;m writing \
this to hopefully have someone more experienced looking at it and help figuring out \
what&#39;s going on.</div><div><br></div><div>Any thought? Should I file it as a \
bug?</div></div>



-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[prev in list] [next in list] [prev in thread] [next in thread]