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