[OE-core] Ownership issue in package contents

[Mark Hatle]

On 3/31/15 4:01 PM, Mario Domenech Goulart wrote:
> On Tue, 31 Mar 2015 15:51:50 -0500 Mark Hatle <mark.hatle at windriver.com> wrote:
> 
>> On 3/31/15 3:33 PM, Mario Domenech Goulart wrote:
>>>
>>> On Tue, 31 Mar 2015 13:23:00 -0500 Mark Hatle <mark.hatle at 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 at intel.com> wrote:
>>>>>
>>>>>> On 27 March 2015 at 17:31, Mario Domenech Goulart <mario at 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.
> 
> I actually had tried that, but I got errors -- probably because the
> ownership will be set for each package that installs ${libexecdir}, and
> which is processed before the recipe that actually creates the
> user/group specified for ${libexecdir} in the file pointed by
> FILESYSTEM_PERMS_TABLES.

This is a bug then.  The owner/group correction is supposed to be made AFTER the
user/groups have been added to the system (sysroot) via the adduser.  THAT is a
bug that IMHO should be fixed sooner, rather then later.

It might be as simple as the install sysroot (${D}) configuration with pseudo
isn't pointing to the right /etc/passwd and /etc/group.  I believe it should be
pointing to the one in the regular sysroot repository.

--Mark

>>> 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.
> 
> Best wishes.
> Mario
>