Ok so let's reconsider this. I was thinking (based on faulty memory) that the problem was just the pty which get opened early on during lxc-start, by the init task itself. But that's not the case, or at least not the whole story. Rather, this is a login spawned by getty in the main console:
300000 2023 1579 0 22:29 ? 00:00:00 /bin/login -- but ls -l in /proc/2023 shows that everything but net, attr, and task are owned by root. Now for the bash spawned by login, everything under /proc/$pid is owned by 300000, the mapped uid. So why is this happening. It's not due to the task's tty. That is /dev/lxc/console which is a bind mount of the host's /dev/pts/7, which is crw------- 1 301000 300005 136, 7 Oct 28 22:36 7 So is there something we can run from userspace while we are still pid 1, before executing /sbin/init, to force ourselves to change to fully "being" 300000 instead of 0? -serge ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
