Wrong file's ownership in rootfs.

Wrong file's ownership in rootfs.

[Grzegorz Mierzejewski]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

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?   Any help and hints would be appreciated.   Best regards,  Grzegorz.

[-- Attachment #2: Type: text/html, Size: 1508 bytes --]

Re: Wrong file's ownership in rootfs.

[Uwe Geuder]

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)