Re: [RFC] systemd the userspace object manager

[Dominick Grift <dac.override@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

On Thu, Nov 20, 2014 at 03:44:19PM -0500, Joshua Brindle wrote:
> 
> I can see why you'd want someone to be able to restart apache but not
> everything. Certainly having specific permissions is not the way to
> accomplish that.
> 
> The rule above is kind of strange, permissions should not be equivalence
> classes, types should be, so it should be more like:
> 
> allow <domain requesting restart> <derived service label> : init {start
> stop}
> 
> right?

If only it were that simple. Here is my take on the whole thing:

Generally services are managed by "service" access checks on unit file types

allow webadmin webserverunitfile:service {start stop};

However these is also a concept of transient (in-memory) unit files, managing a service through a transient unit would work like:

allow user self:service {start stop};

or in the case of transient systemd units:

allow user systemd:service {stop start};

Then there is the system(d) class which also has the start, stop permissions associated with it (it is yet to be determined for what exactly)

In my policy systemd-logind does the following:

allow logind_t systemd:system(d) { start stop };

I suspect that this is required to spawn the systemd session daemon (at least)
It may or may not also be required for kexec (not sure as i havent tested that yet)

This is pretty much just all speculation though, in the sense that this is broadly what i see happening in the system, and it might not be the same as what *should* be happening
Instead its probably better to just read the systemd object manager code

-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]