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