[lxc-users] proc not available inside unprivileged container

[Dr. Todor Dimitrov]

Hello Serge,

> ...  This doesn't show me anything.  Can you show the result of:
> 
> mountpoint /proc
> ls -l /proc

proc was really not mounted :-)

We found the "problem" in the C library, which caches the value returned by getpid. So what happens is the working, mounted proc gets unmounted, then remounted and again unmounted once the container has started. Have a look at this code:

In utils.c:

int lxc_mount_proc_if_needed(const char *rootfs)
{
...
	mypid = getpid();
	INFO("I am %d, /proc/self points to \"%s\"", mypid, link);
  
	if (lxc_safe_int(link, &link_to_pid) < 0)
		return -1;

	/* correct procfs is already mounted */
	if (link_to_pid == mypid) <-- 'I am 13379, /proc/self points to "1"'
		return 0;

	ret = umount2(path, MNT_DETACH); <-- UNMOUNT
	if (ret < 0)
		WARN("failed to umount \"%s\" with MNT_DETACH", path);

domount:
	/* rootfs is NULL */
	if (!strcmp(rootfs, ""))
		ret = mount("proc", path, "proc", 0, NULL);
	else
		ret = safe_mount("proc", path, "proc", 0, NULL, rootfs); <-- MOUNT
	if (ret < 0)
		return -1;

	INFO("mounted /proc in container for security transition");
	return 1;
}

In conf.c:

int lxc_create_tmp_proc_mount(struct lxc_conf *conf)
{
	int mounted;

	mounted = lxc_mount_proc_if_needed(conf->rootfs.path ? conf->rootfs.mount : "");
	if (mounted == -1) {
		SYSERROR("failed to mount /proc in the container");
		/* continue only if there is no rootfs */
		if (conf->rootfs.path)
			return -1;
	} else if (mounted == 1) {
		conf->tmp_umount_proc = 1; <-- MARK FOR UNMOUNTING
	}

	return 0;
}

I wouldn’t consider this a bug, the C library is just very old (uClibc-0.9.33.2).

Thanks for the support,
Todor

> On 7. Jun 2019, at 18:37, Serge E. Hallyn <serge at hallyn.com> wrote:
> 
> On Thu, Jun 06, 2019 at 07:55:04PM +0200, Dr. Todor Dimitrov wrote:
>> Hello,
>> 
>> we have an unprivileged container on LXC 2.1.1, which starts without any errors. The /proc system is however not available/mounted:
>> 
>> ...
>> drwxr-xr-x    2 root     root          1024 Jul 19  2018 proc
> 
> ...  This doesn't show me anything.  Can you show the result of:
> 
> mountpoint /proc
> ls -l /proc
> 
> ?
> 
>> ...
>> dr-xr-xr-x   12 nobody   nogroup          0 Jun  6 17:13 sys
>> ...
>> 
>> /sys on the other hand is present. The network seems to work, we can login with lxc-console, only commands which rely on /proc are non-functional, e.g. mount, ps, etc. The configuration file contains the following line:
>> 
>> lxc.mount.auto = cgroup:rw proc:rw sys:rw
>> 
>> The same configuration runs without any problems on a similar system using the same kernel version (3.12.59). Suspicious in the logs are the following entries:
>> 
>>      lxc-start qivicon 20190606172753.696 DEBUG    console - console.c:lxc_console_peer_default:450 - process does not have a controlling terminal
>>      lxc-start qivicon 20190606172753.848 INFO     lxc_utils - utils.c:lxc_mount_proc_if_needed:1758 - I am 13379, /proc/self points to "1"
>>      lxc-start qivicon 20190606172753.848 INFO     lxc_utils - utils.c:lxc_mount_proc_if_needed:1780 - mounted /proc in container for security transition
>> 
>> On the "working" system, we see:
>> 
>>      lxc-start qivicon 20190606182855.698 DEBUG    console - console.c:lxc_console_peer_default:450 - process does not have a controlling terminal
>>      lxc-start qivicon 20190606182855.731 INFO     lxc_utils - utils.c:lxc_mount_proc_if_needed:1758 - I am 1, /proc/self points to "1"
>> 
>> 
>> Do you have any ideas what the cause of the problem might be?
> 
> Please post the full logs resulting from lxc-start -l debug -o output_file
> 
> -serge
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3868 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20190607/bf3db4dc/attachment.bin>