linux-kernel - Re: Testing lxc 0.6.5 in Fedora 13

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100325213356.GB20541@megiteam.pl>
Date:	Thu, 25 Mar 2010 22:33:56 +0100
From:	Grzegorz Nosek <root@...aldomain.pl>
To:	Matt Helsley <matthltc@...ibm.com>
Cc:	Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Sukadev Bhattiprolu <sukadev@...ibm.com>,
	containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: Testing lxc 0.6.5 in Fedora 13

On wto, mar 23, 2010 at 02:28:34 -0700, Matt Helsley wrote:
> On Sun, Mar 21, 2010 at 08:50:44PM +0100, Grzegorz Nosek wrote:
> 
> <snip>
> 
> > 2. Weird strace behaviour across pidns boundary
> > 
> > When strace'ing (with -ff) lxc-start, I get a proper strace for the
> > directly spawned process and the container init. However, any processes
> > spawned by the container's init are not straced properly (I get two
> > empty files, named <foo>.<pid-in-root-ns> and <foo>.2 -- presumably pid
> > inside the container). The container also seems to malfunction under
> > strace (looks like exec() failing as lxc-ps shows two "init" processes).
> > 
> > This is quite painful as it prevents strace'ing processes in containers
> > even after startup. Here's a snippet of strace'ing a bash (pid 179
> > inside, pid 2959 outside) trying to run 'ls'. The shell hangs until I
> > kill the strace process.
> > 
> > pipe([3, 4])                            = 0
> > clone(Process 197 attached
> > child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7859708) = 197
> > Process 2999 attached (waiting for parent)
> > [pid  2959] setpgid(197, 197)           = 0
> > [pid  2959] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> > [pid  2959] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
> > [pid  2959] close(3)                    = 0
> > [pid  2959] close(4)                    = 0
> > [pid  2959] rt_sigprocmask(SIG_BLOCK, [CHLD TSTP TTIN TTOU], [CHLD], 8) = 0
> > [pid  2959] ioctl(255, TIOCSPGRP, [197]) = 0
> > [pid  2959] rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
> > [pid  2959] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> > [pid  2959] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
> > [pid  2959] waitpid(-1, Process 2959 suspended
> > ^C <unfinished ...>
> > Process 2959 detached
> > Process 197 detached
> > Process 2999 detached
> > 
> > 'strace ls' ran completely inside the container works as expected.
> 
> I'm suprised strace of ls works across pid namespaces. I've been looking
> at strace and it seemed to me that one kernel change and a bunch of strace
> changes are needed to make strace'ing in child pid namespaces work. Eric
> Biederman's setns() patches also might help.

Thanks for the patch and the detailed explanation.

> Can you get a little farther with the kernel fix below?

No, not really. Attaching from outside to a shell running in a container
and running a command yields:

| rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
| pipe([3, 4])                            = 0
| clone(Process 2581 attached (waiting for parent)
| Process 190 attached

Without the patch the order of reported pids is reversed (and at least
with the patched kernel the outside pid is consistently reported first)

| child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7713708) = 190
| [pid  2549] setpgid(190, 190)           = 0
| [pid  2549] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
| [pid  2549] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
| [pid  2549] close(3)                    = 0
| [pid  2549] close(4)                    = 0
| [pid  2549] rt_sigprocmask(SIG_BLOCK, [CHLD TSTP TTIN TTOU], [CHLD], 8) = 0
| [pid  2549] ioctl(255, TIOCSPGRP, [190]) = 0
| [pid  2549] rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
| [pid  2549] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
| [pid  2549] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
| [pid  2549] waitpid(-1, Process 2549 suspended

(the shell hangs here)

^C <unfinished ...>
| Process 2549 detached
| Process 2581 detached
| Process 190 detached

(the command executes here normally).

Best regards,
 Grzegorz Nosek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/