Re: Ownership issue in package contents

[Mark Hatle <mark.hatle@windriver.com>]

On 3/31/15 3:33 PM, Mario Domenech Goulart wrote:
> Hi Mark,
> 
> On Tue, 31 Mar 2015 13:23:00 -0500 Mark Hatle <mark.hatle@windriver.com> wrote:
> 
>> On 3/31/15 12:20 PM, Mario Domenech Goulart wrote:
>>>
>>> On Tue, 31 Mar 2015 14:50:06 +0100 "Burton, Ross" <ross.burton@intel.com> wrote:
>>>
>>>> On 27 March 2015 at 17:31, Mario Domenech Goulart <mario@ossystems.com.br> wrote:
>>>>
>>>>     Note that, although I run "chown -R foo:foo ${D}${libdir}/foo" in
>>>>     the recipe, ./usr/lib/foo/ in the package is owned by root.
>>>>     However, its content has the right ownership.
>>>>
>>>> Looks like a bug in pseudo to me, can you file a bug for that?
>>>
>>> Sure.  Filed #7554.
>>
>> I'd suggest you look at meta/classes/package.bbclass "fixup_perms" function.
>>
>> The ${D}${libdir} (and above) are "corrected" to be 'root:root' by this
>> function.  I don't know why 'foo' would be, but if it's a standard defined
>> variable -- or if 'directory walking' is enabled it could end up doing this as well.
>>
>> The control file for this is in meta/files/fs-perms.txt (unless otherwise
>> defined by a distribution or other configuration file.)
> 
> Thanks a lot.  You seem to have guided me exactly to what causes the
> issue.
> 
>>
>> Format of the file is:
>>
>> # The format of this file
>> #
>> #<path> <mode>  <uid>   <gid>   <walk>  <fmode> <fuid>  <fgid>
> ...
>>
>> The default is:
> ...
>> libexecdir	0755 root root false - - -
> ...
> 
> This variable seems to be the cause of problems:
> 
> $ bitbake -e foo | grep libexecdir=
> export libexecdir="/usr/lib/foo"
> 
> As far as I understand, package.bbclass may use a user-configured
> permissions table (via FILESYSTEM_PERMS_TABLES), but I'm not sure if
> this is the right "fix" for the case in question.  I'd have to hardcode
> the owner of /usr/lib/foo to be "foo", but foo may not be available when
> packaging other recipes.

Ok, good this answers the question as to "why" it's happening.  You can easily
fix this by adding a configuration specific fs-perms.txt file (can name it
anything) that overrides that setting and add it to the FILESYSTEM_PERMS_TABLES.
 You can do this globally in a layer, a distribution or even just a recipe.

In your recipe you can likely do something like:

FILESYSTEM_PERMS_TABLES ?= "files/fs-perms.txt"
FILESYSTEM_PERMS_TABLES += "${THISDIR}/files/recipe-perms.txt"

(Do the ?= first in case it's already set by someone else, then add your recipe
specific perms later)

Contents of the "${THISDIR}/files/recipe-perms.txt":

${libexecdir} 0755 myuid mygid true - myuid mygid

Then you can even skip the chown -R, as the system will do it for you.

> Should libexecdir actually be in the `target_path_vars' variable
> (package.bbclass)?

That is a good question, and something likely worthy of investigating.  Perhaps
removing it from the default set is the correct general purpose change.

I wouldn't do it on an existing release, but its worth considering at the
beginning of a new release.

--Mark

> Best wishes.
> Mario
>