Re: Wrong file's ownership in rootfs.

[Uwe Geuder <jrswdnan22@snkmail.com>]

Hi!


On Fri, May 11, 2018 at 2:42 PM, Grzegorz Mierzejewski <mierzejewskigrzegorz@o2.pl> wrote:
> Hello all,
>
> I have the following problem concerning the file's ownership.
> In my recipe I install the new file to rootfs and change it's ownership in
> do_install function:
> do_install () {
>     install -p -m 644 file1 ${D}/
>     chmod 777 ${D}/file1
>     chown ${USER_DUMMY} ${D}/file1
> }
>
> USER_DUMMY is properly created with useradd class.
> Thing is, that file1 in rootfs do not have the proper ownership - it is
> instead owned by root.
>
> I've checked the pseudo/files.db in recipe's temp folder and ownership is
> proper.
> Also, "bitbake my_package -c devshell" shows proper ownership (as it uses
> files.db).
> But, the same thing done in image's temp folder results in bad (root)
> ownership.
>
> Of course, it happens in modified Jethro delivered by vendor.
> Everything works fine on official Jethro for Wandboard.
>
> Could anyone please give me some hints on what to look for as a root-cause
> of such behavior?
> Or at least describe the process of generating the files.db for image?
> Is it generated based on each package's files.db?
>

I don't know the exact answer. I hope somebody can tell how us to debug
the problem systematically. I have debugged similar issues before
without full success and here is what I happen to remember from the top
of my head

1) Check whether the ipk contains the desired ownership

1a) An ipk is an "ar" file containing 3 files. Extract it like this

$ ar -x tmp/work/corei7-64-poky-linux/openssh/7.5p1-r0/deploy-ipks/corei7-64/openssh-foo_7.5p1-r0_corei7-64.ipk


1b) The files are contained in data.tar.gz

See their owners in textual form using

$ tar tvf data.tar.gz 

(I'm not 100% sure how this relates the checking pseudo as you mention
it. It might lead to the same result. But I feel checking the ipk
contents is less dependent on low level implementation details.)


2) Check out file  poky/meta/files/fs-perms.txt. It's documented in the
mega manual.


3) Could it be some postinst command that changes it? No detailed
   commands from the top of my head :(


4) Debug what you have in ROOTFS_POSTPROCESS_COMMAND

$ bitbake -e my-image-recipe

Maybe something there calls chown?


5) If you cannot find/fix the root cause consider some like

ROOTFS_POSTPROCESS_COMMAND_append = "; hack_protections"

hack_protections () {
  chown 42:42 /foo/bar
}

in your image recipe.

This is completely untested pseudo code, modify until it works :) I have
succcessfully used ROOTFS_POSTPROCESS_COMMANDS, but have never tried for
chown. I am not sure whether you have access to symbolic user/group
names in your recipe.  Depending on what you have done with useradd, the
numerical id might not be fixed.

I vaguely remember that I have used

DEPENDS += "my-useradd"

in a recipe. I think that should make the symbolic ids useradd has created
available to another recipe. I have not done it in an image recipe.


Regards,

Uwe Geuder
Neuro Event Labs Oy
Tampere, Finland
uwe.gexder@neuroeventlabs.com (Bot check: fix one obvious typo)