[OE-core] Ownership issue in package contents
Mark Hatle
mark.hatle at windriver.com
Tue Mar 31 20:51:50 UTC 2015
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 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.
> 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
>
More information about the Openembedded-core
mailing list