From: Michal Ludvig (michal_at_logix.cz)
Date: Tue 05 Apr 2005 - 02:32:59 BST
Herbert Poetzl wrote:
> On Tue, Apr 05, 2005 at 12:41:12PM +1200, Michal Ludvig wrote:
>
>>puck:root:~# /usr/local/sbin/setattr /proc/uptime
>>/proc/uptime: Bad address
>
>
> that is at least unusual ... you sure the kernel was
> compiled with the vserver patch?
Yes, it is. But the binary is somehow broken:
puck:root:~# strace setattr /proc/uptime
execve("/usr/local/sbin/setattr", ["setattr", "/proc/uptime"], [/* 66
vars */]) = 0
[...]
lstat("/proc/uptime", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
SYS_273(0, 0x3f, 0, 0xbffff51e, 0x1) = 65573
SYS_273(0x26020001, 0, 0xbfff9fe0, 0xbffff51e, 0x1) = -1 EFAULT (Bad
address)
[...]
_exit(1) = ?
I'm now recompiling without optimalizations and with debug symbols.
BTW it was linked with dietlibc-0.28
>>2) I created a legacy vserver 'hokpok' with debian-newvserver.sh (0.3.4)
>>from http://www.paul.sladen.org/vserver/debian/
>
> I expect the debian users to do such foolish things ;)
> but now the SuSE folks start using debian-newvserver too?
I just wanted to start from somewhere - never been playing with vservers
before :-)
> please don't! use the tools (vserver <name> build ...)
> to create a new vserver, it will get a proper config
> then ...
Can I automagically create only the configs without building the chroot
tree? There is a nice SuSE tool for installing into directory so I have
the tree ready. Just miss the proper configs...
>>However starting this up dies with
>>---
>>[...]
>>New security context is 49169
>>capchroot: chroot(): Operation not permitted
>
>
> make sure that capabilities are compiled into the kernel
> and not as module ... (or if module that they are properly
> loaded at system bootup)
It is loaded. On the next recompilation I can build it in, but I doubt
it will be any different. I guess the problem is in chcontext-legacy.
>>---
>>Then I even added CAP_SYS_CHROOT and CAP_SYS_ADMIN to the S_CAPS list
>>but to no avail.
>
> don't do that, no caps are required there ... if you
> really use an old (legacy) config please leave S_CAPS=""
I thought legacy should work with the old config. Anyway it doesn't work
even if I omit the "--cap CAP_*" switches.
>>I traced it down to:
>>/usr/local/sbin/chbind --ip 192.168.224.22 --bcast 192.168.224.127 \
>>/usr/local/lib/util-vserver/chcontext-compat --cap CAP_NET_RAW \
>>--cap CAP_SYS_CHROOT --hostname hokpok --secure \
>>/usr/local/lib/util-vserver/legacy/save_s_context \
>>/usr/local/var/run/vservers/hokpok.ctx \
>>/usr/local/lib/util-vserver/capchroot . /etc/init.d/rc 2
>>
>>If I replace chcontext-compat with /usr/local/sbin/chcontext it works
>>much better, so I did _CHCONTEXT_COMPAT=$_CHCONTEXT in util-vserver-vars.
>
>
> that's because you have a legacy config! don't change
> or exchange the tools unless you know what you're doing
> (which you are obviously not ;)
No I don't, but it helped a little bit ;-) I wouldn't have digged here
if it worked before :-)
>>I guess all these problems are caused by the "setattr -> Bad address"
>>issue.
>
> no, but I would investigate this anyway, because
> vprocunhide is very simple ...
If it was miscompiled I guess some other tools may be as well. I'll let
you know if it gets better with non-optimized binaries.
>>Any ideas?
>
> yes, start with the testme.sh and see if it passes all
> tests, if not, then either tools or kernel aren't working
> as expected, and we have to investigate this ...
>
> http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh
Will do...
Thanks,
Michal Ludvig
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver