[OE-core] non uniform directories permissions in sstate-cache

[Andrea Galbusera]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170930/046f1eb0/attachment-0002.html>