#703010 debianutils: ischroot can no longer detect vservers

Package:
debianutils
Source:
debianutils
Description:
Miscellaneous utilities specific to Debian
Submitter:
Andrew Ruthven
Date:
2021-09-16 19:57:02 UTC
Severity:
wishlist
Tags:
#703010#5
Date:
2013-03-11 20:57:48 UTC
From:
To:
[resubmitting as something seems to have gone wrong with creating the bug]

Dear Maintainer,

The ischroot code checks to see if it can access /proc/1/root to determine
if it is a running inside a chroot. Within vservers you can now read
/proc/1/root so it is no longer a sufficient test for vservers.

On newer vserver patches a better check is to look for a VxID line in
/proc/self/status.  If the line is present you're running a vserver
kernel.  If the value is 0, then you're on the physical host, anything
else means you're in a vserver.

Inside a vserver:

puck@build-sid-amd64:/$ grep VxID /proc/self/status
VxID: 12
puck@build-sid-amd64:/$

On the physical host:

build-servers:~$ grep VxID /proc/self/status
VxID: 0
puck@build-servers:~$

I've set this bug report to important as it is stopping initscripts from being
installable on a Wheezy vserver.

This is the case on Linux kernel 3.4 + 2.3.3.9 vserver patch.  The 3.2 kernel
set of patches is not affected by this change of behaviour.

Cheers!
#703010#20
Date:
2013-03-15 08:16:45 UTC
From:
To:
The big downside to that approach that I can see is that according to
the changelog ischroot was implemented to *stop* people having checks
spread all over the place. And as we've just discovered those checks
break over time as things progress. Better to have them in one place,
than spread around.

I guess that question comes down to, is the mount that initscripts
postinst doing appropriate in chroots in general? At a guess no,
otherwise it wouldn't use ischroot.

I have proposed patch for ischroot that is attached to bug #703012
(curse the BTS for not creating my bug reports in a timely manner).

Cheers!
#703010#25
Date:
2013-07-28 00:47:15 UTC
From:
To:
I don't know; it seems pretty stupid to base script behavior on
whether one is in a "chroot" or not.
#703010#30
Date:
2013-07-30 09:00:15 UTC
From:
To:
Totally agree. The problem is with tools that don't run in a chroot, if
they are in a chroot, break horribly. Mostly they're stuff run from
init.d...
#703010#35
Date:
2013-07-30 16:32:43 UTC
From:
To:
I think that's what /usr/sbin/policy-rc.d is for.
#703010#40
Date:
2013-08-08 21:05:36 UTC
From:
To:
Sadly /usr/sbin/policy-rc.d won't fix the initscripts issue as it in is
in the packages postinst. It is all about setting up the /run symlink
and associated bits and pieces.

It takes one approach if it is in a chroot and a totally different
approach if it is a physical host.

The sysvinit postinst script also uses ischroot.

Cheers!
#703010#45
Date:
2018-11-09 20:01:27 UTC
From:
To:
control: tag -1 +moreinfo

On my laptop, there is no VxID in /proc/self/status:

	$ cat /proc/self/status
	Name:	cat
	Umask:	0022
	State:	R (running)
	Tgid:	11990
	Ngid:	0
	Pid:	11990
	PPid:	11989
	TracerPid:	0
	Uid:	1000	1000	1000	1000
	Gid:	1000	1000	1000	1000
	FDSize:	64
	Groups:	24 25 27 29 30 44 46 108 109 111 116 999 1000
	NStgid:	11990
	NSpid:	11990
	NSpgid:	11570
	NSsid:	2243
	VmPeak:	    4172 kB
	VmSize:	    4172 kB
	VmLck:	       0 kB
	VmPin:	       0 kB
	VmHWM:	     744 kB
	VmRSS:	     744 kB
	RssAnon:	      64 kB
	RssFile:	     680 kB
	RssShmem:	       0 kB
	VmData:	     312 kB
	VmStk:	     136 kB
	VmExe:	      28 kB
	VmLib:	    1424 kB
	VmPTE:	      48 kB
	VmSwap:	       0 kB
	HugetlbPages:	       0 kB
	CoreDumping:	0
	Threads:	1
	SigQ:	0/15123
	SigPnd:	0000000000000000
	ShdPnd:	0000000000000000
	SigBlk:	0000000000000000
	SigIgn:	0000000000000000
	SigCgt:	0000000000000000
	CapInh:	0000000000000000
	CapPrm:	0000000000000000
	CapEff:	0000000000000000
	CapBnd:	0000003fffffffff
	CapAmb:	0000000000000000
	NoNewPrivs:	0
	Seccomp:	0
	Speculation_Store_Bypass:	vulnerable
	Cpus_allowed:	f
	Cpus_allowed_list:	0-3
	Mems_allowed:	00000000,00000001
	Mems_allowed_list:	0
	voluntary_ctxt_switches:	0
	nonvoluntary_ctxt_switches:	0
#703010#48
Date:
2018-11-09 20:01:27 UTC
From:
To:
control: tag -1 +moreinfo

On my laptop, there is no VxID in /proc/self/status:

	$ cat /proc/self/status
	Name:	cat
	Umask:	0022
	State:	R (running)
	Tgid:	11990
	Ngid:	0
	Pid:	11990
	PPid:	11989
	TracerPid:	0
	Uid:	1000	1000	1000	1000
	Gid:	1000	1000	1000	1000
	FDSize:	64
	Groups:	24 25 27 29 30 44 46 108 109 111 116 999 1000
	NStgid:	11990
	NSpid:	11990
	NSpgid:	11570
	NSsid:	2243
	VmPeak:	    4172 kB
	VmSize:	    4172 kB
	VmLck:	       0 kB
	VmPin:	       0 kB
	VmHWM:	     744 kB
	VmRSS:	     744 kB
	RssAnon:	      64 kB
	RssFile:	     680 kB
	RssShmem:	       0 kB
	VmData:	     312 kB
	VmStk:	     136 kB
	VmExe:	      28 kB
	VmLib:	    1424 kB
	VmPTE:	      48 kB
	VmSwap:	       0 kB
	HugetlbPages:	       0 kB
	CoreDumping:	0
	Threads:	1
	SigQ:	0/15123
	SigPnd:	0000000000000000
	ShdPnd:	0000000000000000
	SigBlk:	0000000000000000
	SigIgn:	0000000000000000
	SigCgt:	0000000000000000
	CapInh:	0000000000000000
	CapPrm:	0000000000000000
	CapEff:	0000000000000000
	CapBnd:	0000003fffffffff
	CapAmb:	0000000000000000
	NoNewPrivs:	0
	Seccomp:	0
	Speculation_Store_Bypass:	vulnerable
	Cpus_allowed:	f
	Cpus_allowed_list:	0-3
	Mems_allowed:	00000000,00000001
	Mems_allowed_list:	0
	voluntary_ctxt_switches:	0
	nonvoluntary_ctxt_switches:	0
#703010#53
Date:
2018-11-13 05:41:57 UTC
From:
To:
[snip]

That is correct, as I noted it is only present if you are running a
kernel with the vserver patch applied.

Cheers,
Andrew