[lxc-devel] rootfs pinning: make file hidden, don't delete it (but not encode pid)

Jäkel, Guido G.Jaekel at dnb.de
Thu Mar 22 12:50:59 UTC 2018


Dear Serge and others,

actually (at long last) I'm migrating from LXC 0.8.4 to 2.1.1. I'm using NFS as the one-and-only (shared) filesystem for all LXC Hosts and Containers. With this new version there is the rootfs-pinning-mechanism using an open rw handle for the file /lxc.hold to prevent accidentally remounting ro the underlying filesystem by the container.

Currently, this file is opened an unlinked in turn by lxc-start.


lxc/start.c:

        /* If the rootfs is not a blockdev, prevent the container from marking
         * it readonly.
         * If the container is unprivileged then skip rootfs pinning.
         */
        if (!wants_to_map_ids) {
                handler->pinfd = pin_rootfs(handler->conf->rootfs.path);
                if (handler->pinfd == -1)
                        INFO("Failed to pin the rootfs for container \"%s\".", handler->name);

lxc/conf.c:

	int pin_rootfs(const char *rootfs)
	{
	
	[...]
	
	        fd = open(absrootfspin, O_CREAT | O_RDWR, S_IWUSR|S_IRUSR);
	        if (fd < 0)
	                return fd;
	        (void)unlink(absrootfspin);
	        return fd;
	}


Some long years ago, there was a proposal and discussion with Christian Seiler about ...

	http://lxc-devel.linuxcontainers.narkive.com/g1oKn35Q/patch-rootfs-pinning-make-file-hidden-don-t-delete-it-encode-pid

and you, Serge, reject the patch because it introduces a varying name for each use of the rootfs. I agree that one name will be enough. But the ugly NFS quirk with the visible file for a stale handle for each unlinked file will remain. And even worse, it will change its name each time. In my eyes this even more worse than having a "alien" file in the root.

I would like not to unlink the file in case of NFS (or similar) or depending on a config option. And because it will be visible then, use an "hidden" name, maybe with the common term keep) like /.lxc-keep.



Grüße

Guido



More information about the lxc-devel mailing list