Yup, just tested, same still happens.
ls -l /proc/1/* shows everything belonging to root. But picking
my login process,
root 631 1 0 19:43 ? 00:00:00 /bin/login --
I get:
dr-xr-xr-x 2 root ubuntu 0 Jan 2 19:43 attr
-rw-r--r-- 1 nobody nogroup 0 Jan 2 19:43 autogroup
-r-------- 1 nobody nogroup 0 Jan 2 19:43 auxv
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 cgroup
--w------- 1 nobody nogroup 0 Jan 2 19:43 clear_refs
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 cmdline
-rw-r--r-- 1 nobody nogroup 0 Jan 2 19:43 comm
-rw-r--r-- 1 nobody nogroup 0 Jan 2 19:43 coredump_filter
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 cpuset
lrwxrwxrwx 1 nobody nogroup 0 Jan 2 19:43 cwd
-r-------- 1 nobody nogroup 0 Jan 2 19:43 environ
lrwxrwxrwx 1 nobody nogroup 0 Jan 2 19:43 exe
dr-x------ 2 nobody nogroup 0 Jan 2 19:43 fd
dr-x------ 2 nobody nogroup 0 Jan 2 19:43 fdinfo
-rw-r--r-- 1 nobody nogroup 0 Jan 2 19:43 gid_map
-r-------- 1 nobody nogroup 0 Jan 2 19:43 io
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 latency
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 limits
-rw-r--r-- 1 nobody nogroup 0 Jan 2 19:43 loginuid
dr-x------ 2 nobody nogroup 0 Jan 2 19:43 map_files
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 maps
-rw------- 1 nobody nogroup 0 Jan 2 19:43 mem
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 mountinfo
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 mounts
-r-------- 1 nobody nogroup 0 Jan 2 19:43 mountstats
dr-xr-xr-x 5 root ubuntu 0 Jan 2 19:43 net
dr-x--x--x 2 nobody nogroup 0 Jan 2 19:43 ns
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 numa_maps
-rw-r--r-- 1 nobody nogroup 0 Jan 2 19:43 oom_adj
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 oom_score
-rw-r--r-- 1 nobody nogroup 0 Jan 2 19:43 oom_score_adj
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 pagemap
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 personality
-rw-r--r-- 1 nobody nogroup 0 Jan 2 19:43 projid_map
lrwxrwxrwx 1 nobody nogroup 0 Jan 2 19:43 root
-rw-r--r-- 1 nobody nogroup 0 Jan 2 19:43 sched
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 schedstat
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 sessionid
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 smaps
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 stack
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 stat
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 statm
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 status
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 syscall
dr-xr-xr-x 3 root ubuntu 0 Jan 2 19:43 task
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 timers
-rw-r--r-- 1 nobody nogroup 0 Jan 2 19:43 uid_map
-r--r--r-- 1 nobody nogroup 0 Jan 2 19:43 wchan
And, on login I got '-bash: no job control in this shell'
and ctrl-c reboots the container.
status: confirmed
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1263738
Title:
login console 0 in user namespace container is not configured right
Status in “linux” package in Ubuntu:
Confirmed
Status in “lxc” package in Ubuntu:
Triaged
Status in “linux” source package in Trusty:
Confirmed
Status in “lxc” source package in Trusty:
Triaged
Bug description:
When you create a container in a private user namespace, when you start the
container without the '-d' flag, that console is not properly set up.
Logging in
gives you
-bash: no job control in this shell
and hitting ctrl-c reboots the container.
Consoles from 'lxc-console -n $container' behave correctly.
This may be a kernel issue, as discussed here:
http://lists.linuxcontainers.org/pipermail/lxc-
devel/2013-October/005843.html
so also marking this as affecting the kernel.
This can be worked around, but really needs to be fixed before trusty
is frozen.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1263738/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
