By default the root inode of a in-memory filesystem, like ramfs or tmpfs, gets the default security context for that filesystem type. (E.g. via a fs_use_trans statement in a SELinux policy.) For SELinux file context definitions are path based, so whether /srv/data is a sub-directory of the root filesystem or the root directory of a nested filesystem, it should have the same context. Thus when mounting a in-memory filesystem the root node has most likely the wrong context and needs to be relabeled. This for example affects mount units within systemd (systemd/systemd#24917). Some possible solutions (with an addition of a new mount(8) command line flag): I. mount(8) relabels the mountpoint after the mount(2) syscall, via selabel_lookup(3) and setfilecon(3). II. mount(8) adds a rootcontext= option to the mount flags containing the current context of the mountpoint directory. I created a draft adding the special value `!auto`, the exclamation mark should avoid conflicts with valid security contexts, as roocontext= option at https://github.com/util-linux/util-linux/pull/1876. III. introduce a new mount(2) option, rootcontextauto?, on which LSMs can e.g. set the context of the new root inode to the context of the mountpoint. It seems the most obvious place in the kernel would be the set_mnt_opts LSM hook, where SELinux sets initializes all contexts, but this hook is unaware of the mountpoint location, and thus its current context. Current example behavior: $ matchpathcon /var/test /var/test system_u:object_r:var_t:s0 $ mkdir -Z /var/test $ ls -ladZ /var/test drwxr-x---. 2 root root root:object_r:var_t:s0 4096 Oct 4 19:29 /var/test $ mount -t tmpfs tmpfs /var/test $ ls -ladZ /var/test drwxrwxrwt. 2 root root root:object_r:tmpfs_t:s0 40 Oct 4 19:30 /var/test $ restorecon -vn /var/test Would relabel /var/test from root:object_r:tmpfs_t:s0 to root:object_r:var_t:s0
