All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Paul Barker <paul@paulbarker.me.uk>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>,
	OE Core <openembedded-core@lists.openembedded.org>
Subject: Re: dbus build host uid/gid leaking into target home directory
Date: Tue, 14 Oct 2014 11:43:34 +0200	[thread overview]
Message-ID: <20141014094334.GK3000@jama> (raw)
In-Reply-To: <CANyK_8evAyhrmuyHKmk46sfJoF6fwjnF6h9aJoLn4GPGx_Xe1w@mail.gmail.com>

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

On Tue, Oct 14, 2014 at 07:23:52AM +0100, Paul Barker wrote:
> On 13 October 2014 10:13, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> > On Sunday 12 October 2014 16:05:41 Peter A. Bigot wrote:
> >> Pilot error.  This ultimately turned out to be a side-effect of the way
> >> I create my image media: I unpacking the rootfs tar file onto a mounted
> >> sdcard outside the pseudo environment and forgot that tar records
> >> user/group by name not uid/gid.
> >
> > I used to use this method previously, and I guess it can still work if you're
> > not including certain packages in your image - but I wonder if we should note
> > this potential pitfall somewhere in the documentation. I'm not entirely sure
> > where such a note would go, though.
> >
> 
> It probably does need noting somewhere - I've been doing exactly this
> for the last year or so and never even thought that I might be risking
> bad uid/gid values. It makes sense now I think about it but it never
> crossed my mind.
> 
> Looking at 'man tar', there is a '--numeric-owner' option to always
> use numbers for user/group names. It might just be that we need to
> recommend using this option when untarring a rootfs onto a mounted
> volume. This option is present in GNU tar, I'm not sure about other
> implementations, and I haven't given it a proper test, but it looks
> like the thing we want.

It's not supported in busybox's tar implementation at least wasn't with
default config last time I've checked couple years ago - we're using it
since then without any issues.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

  parent reply	other threads:[~2014-10-14  9:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-11 17:16 dbus build host uid/gid leaking into target home directory Peter A. Bigot
2014-10-11 21:10 ` Gary Thomas
2014-10-11 23:14   ` Peter A. Bigot
2014-10-11 23:27     ` Gary Thomas
2014-10-12  6:31       ` Peter A. Bigot
2014-10-12 21:05 ` Peter A. Bigot
2014-10-13  9:13   ` Paul Eggleton
2014-10-13 12:00     ` Peter A. Bigot
2014-10-14  6:23     ` Paul Barker
2014-10-14  9:39       ` Burton, Ross
2014-10-14  9:43       ` Martin Jansa [this message]
2014-10-14  9:45         ` Martin Jansa

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=20141014094334.GK3000@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    --cc=paul@paulbarker.me.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.