On Thu, 17 Jan 2008 16:01:42 +0100, Adam Borowski wrote: > On Thu, Jan 17, 2008 at 01:28:03PM +0000, Anton Piatek wrote: >> I have noticed another error in the logs, there are permission errors >> on /dev/null >> Logging into the chroot reveals /dev/null is 644, not 666 as I would >> expect. >> >> How can I fix the permissions of /dev/null under the chroot? >> >> Are my problems likely to be cause by the fact that my machine is >> running as a vserver? > > Yes, on vserver root is not really root. You can't mknod, mess with > device files, mount filesystems, mess with network, etc. Even some of > the restrictions which have already been fixed on newer versions are by > default (proper paranoia) masked away with machine capabilities. > > Both pbuilder and piuparts fail extremely badly, even though one would > expect them to have support for virtualization. But unless one of us > bothers enough to fix it, the support won't be there. >
Because I am a "raving vserver zealot" I will point out that if you don't mind compromising the host's security inside the vserver, you can add the CAP_MKNOD capability to this vserver, which will enable the ability to make device nodes via mknod and likely will cause pbuilder and piuparts work as advertised. If you add this capability the vserver, you are giving the root access to make random devices inside the vserver, which effectively compromises the entire security isolation point of the vserver model. If you can create the /dev/hda device node and start poking around outside of the security context, then you are asking for trouble. But if its your own box, and you are fine with that, then all you need to do is: echo "CAP_MKNOD" > /etc/vservers/<vservername>/bcapabilities and then restart your vserver. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
