[lxc-devel] problem with user namespace as root

[Michael H. Warfield]

Serge,

Is this going to be another situation where we have to mount a devpts
file system somewhere else and bind mount it into the devtmpfs / tmpfs
file system as a non-priv user?  I recall there have been other problems
(pivot_root) when dealing with tmpfs.  Is this another one?

Regards,
Mike

On Thu, 2014-02-13 at 18:23 -0500, Michael H. Warfield wrote:
> On Thu, 2014-02-13 at 23:44 +0100, Stephan Sachse wrote:
> > On Thu, Feb 13, 2014 at 9:19 PM, Michael H. Warfield <mhw at wittsend.com> wrote:
> > > On Wed, 2014-02-12 at 20:18 +0100, Stephan Sachse wrote:
> > >> i've lost my brain! i'm not a c programmer. someone who knows what
> > >> he's doing, should have a look on it.
> > >
> > > > it errors out with:
> > >
> > > Crud...  Looks like you started showing the info lines AFTER some of the
> > > information I need would have been printed.
> > 
> > here are the complete log
> > 
> > -- 
> > Software is like sex, it's better when it's free!
> > 
> 
> You didn't say if you had applied my experimental patch or not.  I'm
> guessing not but I can't be sure.
> 
> First problem here...
> 
> lxc-start 1392232180.856 ERROR    lxc_conf - Permission denied - Unable
> to create /dev/.lxc for autodev
> 
> I know exactly what that one is.  Unless a setup script is run as root
> prior to an unpriv user starting a container, we can't use the devtmpfs
> at all because an unpriv user can not create /dev/.lxc.  That script is
> "lxc-devsetup" and is called as a prestart script out of the systemd lxc
> service config file.  Since you're on CentOS, you'll have to find that
> script and run it by hand.
> 
> Bottom line is that we're not even using the devtmpfs bind mount stuff
> at this point then, in any case.  You're falling straight back to the
> tmpfs fallback.  That's shown here:
> 
> lxc-start 1392232180.856 DEBUG    lxc_conf - Mounting tmpfs
> to /var/lib/lxc/fedora1/rootfs.dev
> 
> Crap...  I see a bug, but only a bug in my DEBUG statement.  It printed
> the host_path (rootfs.dev) there but we mount to the path (rootfs/dev)
> so we do the right thing and mount the tmpfs in the container itself we
> just say the wrong thing in the message.  I'll have to fix that.
> 
> So the container /dev should have a tmpfs file system mounted on it,
> which was the previous behavior before I did all the devtmpfs work.
> 
> This next message indicates mount_autodev setup succeeded.
> 
> lxc-start 1392232180.856 INFO     lxc_conf - Mounted /dev
> under /usr/lib64/lxc/rootfs
> 
> Now I'm at a loss.  This is indicating a refusal, much further down in
> setup_pts, to allow us to mount a ptyfs file system onto a tmpfs file
> system in the mapped uid case.  But we have to have a tmpfs or devtmpfs
> file system or systemd is going to misbehave horribly in a container.
> 
> Ok...
> 
> 1) DON'T try that experimental patch I posted before.  It won't
> accomplish anything from what I see from these messages.  You don't even
> get that far in that routine before it bails.
> 
> 2) Find the lxc-devsetup script (in lxc/config/init/systemd/lxc-devsetup
> in the source tree) and run that as root to see if we have better luck
> under devtmpfs.
> 
> Serge, this doesn't look like it has anything to do with the devtmpfs
> stuff but is involving tmpfs mounted on dev.
> 
> Regards,
> Mike

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140213/38af559e/attachment.pgp>