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: <20100326115357.GA3345@count0.beaverton.ibm.com>
Date:	Fri, 26 Mar 2010 04:53:57 -0700
From:	Matt Helsley <matthltc@...ibm.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Grzegorz Nosek <root@...aldomain.pl>,
	Matt Helsley <matthltc@...ibm.com>,
	Roland McGrath <roland@...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 Fri, Mar 26, 2010 at 12:11:31PM +0100, Oleg Nesterov wrote:
> On 03/25, Grzegorz Nosek wrote:
> >
> > 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
> 
> Yes, this is broken. More precisely, this wasn't even supposed to work.
> 
> Even stracing of the sub-init itself (or global init btw) has problems,
> the straced init is not protected from unwanted signals.
> 
> > > 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.
> 
> Yes. First of all, tracehook_report_clone_complete() reports the wrong pid nr,
> as it seen inside the init's namespace. This is easy to fix, but I doubt this
> can help. IIRC strace doesn't use PTRACE_GETEVENTMSG at all, it looks at eax
> after syscall.

Yup. strace would need to be modified to use that. I tried that and it still
won't work -- I seem to recall it didn't work because strace uses pid values
obtained from the wait syscall too. To make it work we'd need to be able to
translate those pids in userspace. That's do-able from userspace if you trace
all forks descending from the pidns init task. But it's not do-able for
simple attaches. That's why I was thinking Eric's setns() might be able to
help if strace used it to enter the tracee's pid namespace whenever we need to.

gdb often doesn't use the same methods but has similar problems with pid
namespaces.

Cheers,
	-Matt Helsley
--
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/