[lxc-devel] [PATCH] Support MS_SHARED /

[Dwight Engen]

On Mon, 07 Jan 2013 13:26:44 -0500
"Michael H. Warfield" <mhw at WittsEnd.com> wrote:

> On Tue, 2013-01-08 at 01:32 +0800, Alexander Vladimirov wrote:
> > 2013/1/8 Serge Hallyn <serge.hallyn at canonical.com>:
> > > Quoting Alexander Vladimirov
> > > (alexander.idkfa.vladimirov at gmail.com):
> > >> Just like on the host:
> > >> [idkfa at s10 ~]$ ls -la /dev/{null,tty,urandom,zero,full}
> > >> crw-rw-rw- 1 root root 1, 7 янв  6 13:30 /dev/full
> > >> crw-rw-rw- 1 root root 1, 3 янв  6 13:30 /dev/null
> > >> crw-rw-rw- 1 root tty  5, 0 янв  8 00:03 /dev/tty
> > >> crw-rw-rw- 1 root root 1, 9 янв  6 13:30 /dev/urandom
> > >> crw-rw-rw- 1 root root 1, 5 янв  6 13:30 /dev/zero
> > >>
> > >> For example
> > >
> > > You say "for example", implying there is another.  I don't see it
> > > though. What else is different?
> 
> > I'm sure I have encountered error messages about /dev/null
> > permissions at some point, but I can't reproduce it atm

I noticed permission problems with /dev/null here on my F17 test box as
well (dhcp-client-script in the container couldn't >/dev/null), it was
the SELinux labels, on the host they are:

drwxr-xr-x. root root system_u:object_r:device_t:s0    /dev
crw-rw-rw-. root root system_u:object_r:null_device_t:s0 /dev/null

my container has:

drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /dev
crw-rw-rw-. root root unconfined_u:object_r:default_t:s0 /dev/null

Don't know if this is the cause of what your seeing though.

> I've actually seen that.  I was experimenting with different
> containers and enabled audodev on an F14 container to see what would
> happen.  I got the error on /dev/null.
> 
> Oh, crap...  I just went to retest this scenario on Forest (my F17
> host and test engine) after having done a yum update.  That last
> update updated systemd to -44 and now I've got the pivot root problem
> on Fedora 17 as well.  Anyone running lxc on Fedora 17 is going to
> get broken even for non-systemd containers with the latest
> update.  :-P  Ok...  Put latest stage over on my F17 to fix THAT
> problem now.
> 
> Reproduced this with my F14 container, Plover.  Started it up and then
> sshed to it from my workstation...
> 
> [mhw at canyon ~]$ ssh plover.ip6.wittsend.com
> Last login: Mon Jan  7 13:02:35 2013 from canyon.ip6.wittsend.com
> -bash: /dev/null: Permission denied
> -bash: /dev/null: Permission denied
> -bash: /dev/null: Permission denied
> -bash: /dev/null: Permission denied
> -bash: /dev/null: Permission denied
> -bash: /dev/null: Permission denied
> -bash: /dev/null: Permission denied
> -bash: /dev/null: Permission denied
> -bash: /dev/null: Permission denied
> -bash: /dev/null: Permission denied
> [mhw at plover ~]$ ls -l /dev
> total 0
> crw-------. 1 root tty  136, 3 Jan  7 13:16 console
> crwxr-xr-x. 1 root root   1, 7 Jan  7 13:15 full
> lrwxrwxrwx. 1 root root      7 Jan  7 13:15 kmsg -> console
> srw-rw-rw-. 1 root root      0 Jan  7 13:15 log
> crwxr-xr-x. 1 root root   1, 3 Jan  7 13:15 null
> lrwxrwxrwx. 1 root root     13 Jan  7 13:15 ptmx -> /dev/pts/ptmx
> drwxr-xr-x. 2 root root      0 Jan  6 12:14 pts
> crwxr-xr-x. 1 root root   1, 8 Jan  7 13:15 random
> crwxr-xr-x. 1 root root   5, 0 Jan  7 13:15 tty
> crwxr-xr-x. 1 root root   1, 9 Jan  7 13:15 urandom
> crwxr-xr-x. 1 root root   1, 5 Jan  7 13:15 zero
> 
> When I saw that before, I couldn't figure out how or why that was
> happening while reading the C code but, now, knowing MAKEDEV is
> getting called, I have to wonder if there's some sort of interaction
> here.  When I was looking at that code before, I wasn't aware that
> MAKEDEV was being called before trying to create those devices.  I
> was just ignoring that case since it was just testing autodev on a
> non-systemd container.
> 
> Mike
> 
> > >> /dev/tty not being group-writable leads to the following
> > >> error when I login through ssh:
> > >>  sshd[79]: error: open /dev/tty failed - could not set
> > >> controlling tty: Permission denied
> > >
> > > Interesting.  Mine definately is owned by group tty, and it's not
> > > userspace changing it after boot, since even
> > >    lxc-start -n r2 -- /bin/sleep 100
> > > with lxc.autodev = 1 gets /dev/tty owned by group tty.  I don't
> > > understand why though as I don't see any place in src/lxc/conf.c
> > > where I chown it.
> > 
> > That is why I called permissions "strange", quick look at the source
> > made no insights on what's happening.
> > 
> > > Do you have the same result (just to help me figure out what's
> > > going on, not to suggest you should have to do this) if you add
> > >
> > > lxc.devttydir = lxc
> > 
> > Doing this just moves /dev/console into subdir, but /dev/console has
> > correct group and permissions regardless of this option.
> > For /dev/tty and other nodes in question that option does not
> > change anything.
> > 
> > >
> > > thanks,
> > > -serge
> > 
>