In the context of packaging Xen, I'm looking for the Right Way(tm) to mount a tmpfs with a suitable security context.
= Background =
xenstored is a daemon run in a Xen domain 0 (control domain). It acts as a sort of registry that domains and the toolstack can use to communicate and store important information.
xenstored uses a simple database stored in /var/lib/xenstored/tdb . This file is not persistent across reboots, it is fairly small, and the access speed has a major impact on the speed of the system. For this reason, mounting /var/lib/xenstored as a tmpfs results is highly recommended.
The Xen project ships a number of recommended systemd initscripts with its distribution. One of these is var-lib-xenstored.mount, which simply mounts tmpfs on /var/lib/xenstored. xenstored.service requires var-lib-xenstored.mount.
The default CentOS selinux policies in /etc/selinux/targeted/modules/active/file_contexts contain labels for xenstored:
/var/lib/xenstored(/.*)? system_u:object_r:xenstored_var_lib_t:s0 /usr/sbin/xenstored -- system_u:object_r:xenstored_exec_t:s0
(Presumably somewhere there's a connection defined between the two labels; I haven't found it yet.)
The security context for /var/lib/xenstored is set automatically (I presume due to the above rule):
# ls -aZ /var/lib/xenstored/ drwxr-xr-x. root root system_u:object_r:xenstored_var_lib_t:s0 .
= The Problem =
When var-lib-xenstored.mount mounts tmpfs at /var/lib/xenstored, the security context reverts to the default for tmpfs:
# systemctl start var-lib-xenstored.mount # ls -aZ /var/lib/xenstored/ drwxr-xr-x. root root system_u:object_r:tmpfs_t:s0 .
SELinux subsequently denies permission to xenstored to access the location, and xenstore fails.
= Discussion =
The version of var-lib-xenstored.mount in Xen 4.5 contains a security context in the mount options, which can be set at configure time; the result looks something like this:
Options=mode=755,context=system_u:object_r:xenstored_var_lib_t:s0
Unfortunately, the way this was set up meant that if your system did *not* have selinux, then the mount would fail. So this was removed, leaving us the way things are above.
I *could* patch var-lib-xenstored.mount in my xen package; but I would like to avoid patches as much as possible. Furthermore, as someone whose main job is to be an upstream Xen developer, I would prefer to make var-lib-xenstored.mount as useful as possible *by default*, without needing to be patched / modified by people downstream using selinux.
One solution which has been proposed is to use a config file (say, /etc/sysconfig/xenstored) which contains a custom set of options for var-lib-xenstored.mount.
However, when poking around, I couldn't find any other places where a context is manually added to a mounted place like that, which made me wonder if there was a better, more generic way to automatically get things to work properly.
I did some poking around, and found that /usr/lib/systemd/rhel-readonly mounts things with tmpfs, and sorts out the selinux stuff by running restorecon after mounting it. I tried that, and it seems to work:
# restorecon -R /var/lib/xenstored # ls -aZ /var/lib/xenstored/ drwxr-xr-x. root root system_u:object_r:xenstored_var_lib_t:s0 .
Running "systemctl start xenstored.sevrice" afterwards gets a working xenstore.
So I guess I was wondering if there was a better way to get /var/lib/xenstored labelled with the right contexts than trying to shove the contexts in at mount time. Is there a way to have systemd automatically call restorecon after mounting the filesystem? Or is there a better way to get systemd to mount a suitable tmpfs at /var/lib/xenstored?
Thanks, -George