image_type.bbclass: add '--numeric-owner' to tar command
cover image_type.bbclass: add '--numeric-owner' to tar command
From: Chen Qi <[email protected]>
The following changes since commit 529bf977e956175bd8405ebffc88194192e44740:
update-rcd.bbclass: fix host/target test (2013-10-16 14:51:07 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib ChenQi/tar-numeric-owner
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/tar-numeric-owner
Chen Qi (1):
image_types.bbclass: add --numeric-owner option to tar command
meta/classes/image_types.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Signature · 1 line
1.7.9.5
PATCH 1/1 image_types.bbclass: add --numeric-owner option to tar command
From: Chen Qi <[email protected]>
If the same username exists on both target and the build host, but the uids differ, and we start target via NFS, then the uid for the user will be incorrect on target.
For example, if postfix's uid on host is 119 and on target is 1024, then if we start target via NFS, the uid for postfix will be 119.
The root cause is that when we use runqemu-extract-sdk to generate the NFS rootfs for later use, the tar command will respect the username instead of uid. So if PSEUDO_PASSWD environment is not set correctly, the host /etc/passwd will be used, resulting in wrong uids.
The situation for gid is completely analogous to that of uid.
It's almost impossible for the runqemu-extract-sdk to guess the correct location of the needed password file merely based on the target tarball name.
This patch solves this problem by adding the '--numeric-owner' option to the tar command so that the username/groupname is not recorded in the tarball. In this situation, we'll always get the correct uid/gid after extracting the tarball.
[YOCTO #5364]
--- meta/classes/image_types.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/image_types.bbclass +1 -1
@@ -171,7 +171,7 @@ IMAGE_CMD_btrfs () { IMAGE_CMD_squashfs = "mksquashfs ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.squashfs ${EXTRA_IMAGECMD} -noappend" IMAGE_CMD_squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.squashfs-xz ${EXTRA_IMAGECMD} -noappend -comp xz" -IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar ." +IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar --numeric-owner -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar ." CPIO_TOUCH_INIT () { if [ ! -L ${IMAGE_ROOTFS}/init ]
Signature · 1 line
1.7.9.5
Re: [PATCH 1/1] image_types.bbclass: add --numeric-owner option to tar command
Quoted 25 lines · On Fri, 2013-10-18 at 15:47 +0800, [email protected] wrote:
From: Chen Qi <[email protected]>
If the same username exists on both target and the build host, but the uids differ, and we start target via NFS, then the uid for the user will be incorrect on target.
For example, if postfix's uid on host is 119 and on target is 1024, then if we start target via NFS, the uid for postfix will be 119.
The root cause is that when we use runqemu-extract-sdk to generate the NFS rootfs for later use, the tar command will respect the username instead of uid. So if
PSEUDO_PASSWDenvironment is not set correctly, the host/etc/passwdwill be used, resulting in wrong uids.The situation for gid is completely analogous to that of uid.
It's almost impossible for the runqemu-extract-sdk to guess the correct location of the needed password file merely based on the target tarball name.
This patch solves this problem by adding the '--numeric-owner' option to the tar command so that the username/groupname is not recorded in the tarball. In this situation, we'll always get the correct uid/gid after extracting the tarball.
Quoted 6 lines
[YOCTO #5364]
Signed-off-by Chen Qi <[email protected]>--- meta/classes/image_types.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Er, isn't the right fix to fix runqemu-extract-sdk to use numeric IDs then rather than butcher all the tarballs we create?
Cheers,
Richard
Re: [PATCH 1/1] image_types.bbclass: add --numeric-owner option to tar command
Quoted 32 lines · Richard Purdie
Quoted 25 lines · On Fri, 2013-10-18 at 15:47 +0800, [email protected] wrote:
From: Chen Qi <[email protected]>
If the same username exists on both target and the build host, but the uids differ, and we start target via NFS, then the uid for the user will be incorrect on target.
For example, if postfix's uid on host is 119 and on target is 1024, then if we start target via NFS, the uid for postfix will be 119.
The root cause is that when we use runqemu-extract-sdk to generate the NFS rootfs for later use, the tar command will respect the username instead of uid. So if
PSEUDO_PASSWDenvironment is not set correctly, the host/etc/passwdwill be used, resulting in wrong uids.The situation for gid is completely analogous to that of uid.
It's almost impossible for the runqemu-extract-sdk to guess the correct location of the needed password file merely based on the target tarball name.
This patch solves this problem by adding the '--numeric-owner' option to the tar command so that the username/groupname is not recorded in the tarball. In this situation, we'll always get the correct uid/gid after extracting the tarball.
Quoted 6 lines
[YOCTO #5364]
Signed-off-by Chen Qi <[email protected]>--- meta/classes/image_types.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Quoted 9 lines
Er, isn't the right fix to fix runqemu-extract-sdk to use numeric IDs then rather than butcher all the tarballs we create?
Cheers,
Richard
Thanks for pointing it out.
V2 has been sent out.
Best Regards,
Chen Qi