[Pkg-sysvinit-devel] Bug#633845: initscripts: unupgradeable on vserver

[Roger Leigh]

On Thu, Jul 14, 2011 at 03:11:12PM +0000, Clint Adams wrote:
> On Thu, Jul 14, 2011 at 02:04:15PM +0100, Roger Leigh wrote:
> > CCing Clint and Aurelien: Does this type of check belong in
> > "ischroot", or would it need adding to a separate (e.g. "isvserver")
> > tool?  Is the scope of ischroot limited to plain chroot(2) chroots,
> 
> Is the objective here to find out if one is running in a
> "jailed" filesystem namespace but with full access to a
> global process namespace?

It's mentioned earlier in the bug history.  Essentially, at least
in the initscripts case, we don't want to bind mount filesystems
(/var/run on /run) in the chroot case (since the rcS.d scripts
won't run to complete the transition).  In the vserver case it's
simply not possible to do any mounting inside the vserver, and so
we need to treat it as if it was a chroot (I'm fairly sure it doesn't
run rcS scripts either).

So our query is not exactly "is it a chroot?", but
"does it run the rcS scripts".  Both chroots and vservers are "no"
for both questions, so we are using the chroot check as a proxy
for the rcS script question (since we can't find out directly).
In our initial "guest_environment" shell function (which is what
became ischroot IIRC) we also had logic to check for a vserver and
treat it like a chroot.  Note that in a vserver, ischroot always
fails because /proc/1/root is not readable, even by root, so we
need to check /proc/self/vinfo instead.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20110714/5e0ae5f4/attachment.pgp>