From: "Peter A. Bigot" <pab@pabigot.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 2/2] image_types.bbclass: add tar --numeric-owner support
Date: Sun, 02 Nov 2014 09:10:28 -0600 [thread overview]
Message-ID: <54564964.60906@pabigot.com> (raw)
In-Reply-To: <1414940466.5111.0.camel@ted>
On 11/02/2014 09:01 AM, Richard Purdie wrote:
> On Sun, 2014-11-02 at 04:48 -0600, Peter A. Bigot wrote:
>> tar format normally stores user and group as names, which is the right
>> thing to use when target passwd and group files are available. When
>> unpacking a rootfs archive onto a mounted SD card partition on a build
>> host outside the pseudo environment the host passwd/group files will be
>> used for name-to-id mapping, which results in mis-assigned identifiers
>> (often for important ids like messagebus).
>>
>> Using IMAGE_FSTYPES += "nug.tar" creates rootfs.nug.tar files where the
>> owner and group are specified numerically, using the target IDs obtained
>> when the archive is built under pseudo.
>>
>> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
>> ---
>> meta/classes/image_types.bbclass | 2 ++
>> 1 file changed, 2 insertions(+)
> Shouldn't we always do this?
>
> I'm trying to figure out when this would be a bad idea...
I read
http://www.mail-archive.com/openembedded-core%40lists.openembedded.org/msg45147.html
as suggesting you thought otherwise.
But no, I think using names is generally appropriate. It's what the
underlying packages use (well, RPM at least; I didn't check others).
It's nice in that it does allow you to see the owner and group from tar
-tav without having to unpack /etc to get the uid/gid mappings. If you
unpack it on a development machine to see what's in it, chances are the
files will end up owned by the right users. And it works just fine in
the standard Yocto environment that uses pseudo to map names, as
(perhaps) wic using it to create a new custom rootfs might do.
Pretty much the only situation where it doesn't work is unpacking it as
root not using pseudo in a context you really want the resulting uid/gid
to be what they'll be on the target. That's a pretty important use
case, but not IMO enough to change the default from what it's "always
been", especially as it'll go away once wic matures a little.
Peter
next prev parent reply other threads:[~2014-11-02 15:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-02 10:48 [PATCH 0/2] support numeric owner/group tar image format Peter A. Bigot
2014-11-02 10:48 ` [PATCH 1/2] image_types.bbclass: whitespace and reorder Peter A. Bigot
2014-11-02 10:48 ` [PATCH 2/2] image_types.bbclass: add tar --numeric-owner support Peter A. Bigot
2014-11-02 15:01 ` Richard Purdie
2014-11-02 15:10 ` Peter A. Bigot [this message]
2014-11-03 14:55 ` [PATCH 0/2] support numeric owner/group tar image format Mark Hatle
2014-11-03 15:19 ` Peter A. Bigot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54564964.60906@pabigot.com \
--to=pab@pabigot.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox