Openembedded Core Discussions
 help / color / mirror / Atom feed
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



  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