On Tue, Dec 21, 2010 at 03:13:24PM +0800, Jeff Jansen wrote:
> On Monday 20,December,2010 02:36 PM, Herbert Poetzl wrote:
> > first, I'd update to 2.6.36.x with the latest patch and the
> > most recent util-vserver, because that's where all the
> > updates and fixes go, and check that the 'issue' still
> > exists there ...
> I compiled "linux-2.6.36.2" patched with
> "patch-2.6.36.2-vs2.3.0.36.38.2.diff", and
> "util-vserver-0.30.216-pre2926". I still see the same issue when I run
> a lucid guest using the new kernel and util-vserver.
> Versions:
> Kernel: 2.6.36.2-vs2.3.0.36.38.2
> VS-API: 0x00020307
> VCI: 0x0000000013110f91
> util-vserver: 0.30.216-pre2926; Dec 21 2010, 09:46:13
> When I try to start the ssh server (which has an "expect fork" in the
> "/etc/init/ssh.conf" file), it fails with the following error in the logs:
> Dec 21 10:47:41 LUCID init: Failed to spawn ssh main process: unable to
> set trace: Operation not permitted
> "strace -f -p 1" in the guest shows
> [pid 13635] ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not
> permitted)
this is actually quite interesting because:
- strace uses sys_ptrace() so the ptrace itself seems to be fine
(i.e. I presume your guest has CAP_SYS_PTRACE)
- upstart? fails to use sys_ptrace() with EPERM
(i.e. permission denied)
checking the code gives the following reasons for that:
- credentials wrong (uid/gid)
- CAP_SYS_PTRACE missing
- different xid (this is Linux-VServer specific)
- security framework check
as I presume that upstart is running in the same guest context
I can almost certainly rule out the xid check, which makes me
wonder what actually causes your EPERM ...
if you are interested in tracking this down, please pay a visit
to the IRC channel (#vserver @ irc.oftc.net) where we can debug
this in detail (you need a test system and a kernel build tree
to test with :)
> If I go into "/etc/init/ssh.conf" and comment out the "expect fork" line
> and then change 'exec sshd' to 'exec sshd -d' (so sshd won't fork), then
> SSH starts and stops correctly using upstart.
I presume this simply disables the ptrace completely, note
that I'm not convinced that ptracing services is a good idea
in the first place, mainly because of performance implications
best,
Herbert
> Jeff Jansen
Received on Tue Dec 21 16:01:17 2010