Investigate additional systemd private types for sessions and inhibit directories.

[pebenito]

From @bigon:

Fedora policy add a new "systemd_logind_sessions_t" for the /var/run/systemd/sessions directory.

Some other application that check if a session is existing or active (policykit, colord,...) are explicitly reading the files inside this directory and I'm not sure we should them access the other ones

Also:

Same here, fedora also use a different type (systemd_logind_inhibit_var_run_t).

Looking at their policy they allow NetworkManager, devicekit, telepathy, libvirt,...) to write there. see: systemd_write_inhibit_pipes() interface:

allow $1 systemd_logind_inhibit_var_run_t:fifo_file write;

[ghost]

I suspect that this is a bit expensive if the sole purpose is to differentiate between the inhibit and sessions pipes.

In my policy all systemd-logind runtime content is of the same type. So if a process can write the inherited inhibit pipe then it can also write the inherited sessions pipe i suppse. It makes the policy simpler but you will lose a little control (but in my policy i decided to trust system-logind with the decision whether something can inhibit or not for the sake of simplicity)

[ghost]

Then again, it may be compelling to do this

systemd-inhibit seems to be basically a wrapper. priv users can use it to run almost anything

example: systemd-inhibit sleep 10

That means that you basically have to treat it like an interpreter.

So if you want a user to be able to run systemd-inhibit, then you must allow that user to write the inherited inhibit pipe (plus the user must be able to dbus chat with systemd-logind (and be a system bus client)

So if you do not differentiate then any user that needs to be able to run systemd-inhibit will also be able to write the sessions pipe and this may not be desired.

So yes, it is expensive but kind of compelling.

[ghost]

Last comment for now on this:

I agree that it may be useful to differentiate between /run/systemd/sessions and /run/systemd/inhibit

The more because it seems that operation on the former is limited to privileged processes whereas operation on the latter is not (any process needs to be able to inhibit/delay shutdown)

For example consider a user writing an disk image to an optical disk (as per the systemd-inhibit man page example)