[yocto] Change in 'devshell' behaviour

[Richard Purdie]

On Fri, 2013-04-19 at 08:52 -0600, Gary Thomas wrote:
> CAUTION!! giant security hole awaits!
> 
> I've just discovered that recent Poky/Yocto runs 'devshell' as ROOT!
> 
> If I run 'bitbake SOME-RECIPE -c devshell' with a somewhat older
> metadata (poky rev 09359e6ec00901abfe49157f1f9730117b4d284b)
> the shell is run using my user id.
> 
> With a newer poky rev 90b98764555945a186562ca8d501a9585ce2b23f,
> the shell runs as 'root'.
> 
> This change came with this revision:
> 
> commit 4dc31a327be1a506e78e1d028db08ceee22a216f
> Author: Richard Purdie <richard.purdie at linuxfoundation.org>
> Date:   Thu Mar 28 13:17:12 2013 +0000
> 
>      base.bbclass: When we use fakeroot, also use it for devshell
> 
>      Its generally useful for devshell to end up in the fakeroot environment. If
>      a user needs to exit it, PSEUDO_UNLOAD=1 <command> works, its usually
>      harder to enter the envionment.
> 
>      [YOCTO #3374]
> 
>      (From OE-Core rev: e6ffc747a8ca5142c9bc6fbd2b06b5808bb38b02)
> 
>      Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
> 
> Isn't this a horrible security flaw?  Or is 'fakeroot' actually safe?
> The change description doesn't tell me why it's "useful".
> 
> Whatever the case, to me at least it's very unnerving...

I think the key word to look at here is "fake". You'll find you can't do
anything nasty to your system you couldn't do as your normal user
account and this is purely emulation.

This "root" context is the one do_install, do_populate_sysroot and other
tasks run under so that we can give files owners and permissions in the
packages. We chose to give it more visibility since its actually useful
for debugging several types of problems. For example, you can look
around the rootfs from the rootfs task and see real users as it would
get tarballed up.

You can get your normal shell back with "PSEUDO_UNLOAD=1 bash", which is
much easier than trying to get into the pseudo context in the first
place.

So please rest assured there is no security issue here.

Cheers,

Richard