[OE-core] Directory permissions and ownership -- RFC

[Mark Hatle]

On 6/21/11 1:57 PM, Phil Blundell wrote:
> On Tue, 2011-06-21 at 11:43 -0500, Mark Hatle wrote:
>> Adjust the umask to 022.  This resolves the problem of dynamically generated
>> directories (mkdir -p) and specific files (touch foo) having odd permissions.
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatle/perms&id=d8470b6a8efdbba04cef5d4dc1ce12720fe83621
> 
> Are you confident that this isn't going to break anything like
> group-shared DL_DIRs?  I'm not entirely thrilled about forcing the umask
> to 022 for everything that bitbake does, although I can see that making
> it be so for particular tasks like do_install() might have some merit.
> Even in the latter case, though, I wonder whether we should just be
> paying more attention to recipe hygiene and using "install -m ..." with
> the permissions that we actually want.

This is why I bring this up.. I'm a bit concerned that doing it generally will
have unintended consequences.  So far I am not aware of any.  Moving it to a
different place in the process may be better.  The only issue I've found so far
is that just coding int into "do_install" really isn't an option.  Between the
custom do_install components, various classes, etc.. it's difficult in the
current infrastructure to find a centralized location to set the value.

(I'd love to be corrected if someone things of another way of doing it.)  The
setting of the umask is a very low cost operation, so doing it for certain steps
shouldn't cause a performance penalty... but until we figure that out this is
the best and easiest solution I've come up with.

> I'm also not quite sure I understand why this is necessary if
> fixup_perms is going to fix up the permissions anyway. 

fixup_perms only knows of certain global directories, it doesn't know of ones
that may or may not be unique to given packages, or sets of packages.  (yes they
could be added over time to the fs-perms.txt file.  I started down this path,
and when the file reached a few hundred lines I gave up and went to the root
cause.. mismatched umask.)

(The global directories are the standard GNU ones, specified in bitbake.conf,
and a hand full of specific documentation and similar...  I could have put these
into the fs-perms.txt, but keeping them dynamic ensures that if someone changes
the value of "libdir", we don't have to specify anything for it to work properly.)

The umask fixes both the directories we should know about, and those we'll never
know about -- recipes that don't exist in oe-core/meta-oe...  It also has a side
effect of ensuring that the recipe author only has to pay attention to basic
recipe tasks, and not do a full world build and look for conflcts.

A good example of the problem is that cups generates a directory /etc/cups and
sets the perms to 0755 w/ uid/gid of root:lp.  When ghostscript comes along to
put something in /etc/cups, it does a "mkdir -p /etc/cups"...  that means
/etc/cups now gets the default mode, uid/gid...  Changing "ghostscript" to match
is easy, it's one package... but what happens when someone adds HP printer
drivers, then epson printer drivers, etc..  you quickly get into a situation
where you really want a global way to affect /etc/cups, and potentially
everything located inside of it.

>> The user can add their own settings, or override the defaults by providing a
>> meta/files/fs-perms.txt file. 
> 
> Using a magically-named file rather than metadata vars is a bit
> unconventional and seems like it will make life unnecessarily harder for
> distros/other overlays.  Is there any reason it needs to be done that
> way?

fs-perms.txt is the default name.  It was done to work similarly to the
'device_table-minimal.txt' file that already exists.

The logic is:

Use the variable FILESYSTEM_PERMS_TABLES, the contents of this may be full
paths, or partial paths within the BBPATH structure.  Multiple files may be
listed space separated.  (Evaluation is is order it's specified, so the last one
loaded takes precedence over earlier ones.)

If the variable FILESYSTEM_PERMS_TABLES is not specified, we then use the
files/fs-perms.txt, again BBPATH is searched for that.

--Mark

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core