[yocto] Wrong file's ownership in rootfs.
Uwe Geuder
jrswdnan22 at snkmail.com
Fri May 11 09:51:46 PDT 2018
Hi!
On Fri, May 11, 2018 at 2:42 PM, Grzegorz Mierzejewski <mierzejewskigrzegorz at 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 at neuroeventlabs.com (Bot check: fix one obvious typo)
More information about the yocto
mailing list