[systemd-devel] systemctl as non-root

Dimitri John Ledkov dimitri.j.ledkov at intel.com
Fri May 29 01:54:16 PDT 2015


On 29 May 2015 at 01:21,  <Aaron_Wright at selinc.com> wrote:
> Brandon Philips <brandon at ifup.co> wrote on 05/28/2015 05:10:33 PM:
>> Access to the system dbus is controlled by dbus policies. You will
>> need to write a policy for giving this user access to the systemd1 object.
>>
>
> I compiled systemd without dbus support (--disable-dbus), and there is no
> dbus daemon or dbus lib on the system. Is that a requirement to get the
> functionality I want? I didn't see much need for dbus as the system works
> quite well without it. Well, except for this of course.
>

the term dbus is used loosely and it's a few distinct things. On the
most basic level, it's used as a marshalling/demarshling format of
messages passed to/from systemd, on the protocol level this is exposed
via private socket or systemd may join the system bus which is
operated by something, e.g. kdbus or the dbus1 daemon. When there is a
dbus daemon available policy can be checked and enforced and e.g.
unprivilledged users can be granted to execute certain actions on per
dbus api level. Further more policykit can be used in conjunction with
that to seamlessly ask to elevate / allow more privileged api calls.
However just on the private systemd socket these complex measures are
not available and one really needs to be root...

... if not done carefully, it is easy to introduce vulnerabilities
into the system e.g. if one allows unprivileged things start/stop
privileged jobs.


>> On May 28, 2015 2:28 PM, <Aaron_Wright at selinc.com> wrote:
>>> I'm working on an embedded system, and I ran into a situation where
>>> a non-root user needs to runs systemctl, but when I try I get:
>>> ~ $ systemctl status
>>> Failed to get D-Bus connection: No such file or directory
>>>
>>> So, I try with the suid bit on systemctl set, but then I get:
>>>
>>> ~ $ systemctl status
>>> Failed to read server status: Operation not permitted
>>>
>>> My question is, is something broken, or is this expected behavior?
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.


More information about the systemd-devel mailing list