[refpolicy] systemd policy

Christopher J. PeBenito cpebenito at tresys.com
Tue Jan 14 08:34:49 EST 2014

On 01/13/14 18:37, Russell Coker wrote:
> On Mon, 13 Jan 2014 10:10:11 Daniel J Walsh wrote:
>> Having separate labels on the unit file is not just for "user" domains.   It
>> is also for system domains, for example NetworkManager_t is allowed to
>> start the following services.
> OK.
> I've attached a patch I'm using which defines some unit types and adds fc 
> entries.  Some of them are missing fc entries, presumably because the daemons 
> in question didn't have unit files at the time (this policy was taken from 
> Fedora some time ago).
> I've also added a stub systemd_unit_file() in init.if.  The full systemd policy 
> patch will have to remove that.  I think this is OK to get the uncontroversial 
> stuff included in the tree sooner.

I don't have a problem with something like this.  The big thing that concerns me about integrating systemd policy is it's structure.  My big question is can we add it onto the init module and toggle rules (similar to init_upstart tunable) reasonably?  Or does is it so different than sysvinit/upstart that it deserves to be implemented as a replacement module for init?  If that's the case, that would surely have some interesting issues (e.g. what to do about initrc_t etc.)  There's also questions about the socket activation and how that fits in.

I've been dragging my feet on integrating systemd stuff since I don't have such a good sense of the answers to these questions (and systemd functions were in flux for a long time.)  A couple months ago I tried setting up systemd on one of my Gentoo systems, but that didn't go well, since its not well supported (a lot of Gentoo devs reject it's use).  I haven't had a chance to retry on a Fedora system.

That being said, I do want to get support in by the time RHEL7 final goes out.

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

More information about the refpolicy mailing list