diff options
author | Lennart Poettering <lennart@poettering.net> | 2013-12-10 16:41:39 +0000 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2013-12-10 16:52:49 +0000 |
commit | adacb9575a09981fcf11279f2f661e3fc21e58ff (patch) | |
tree | 2be66e6581ee0ff80dbfa16821f2e448e9bab0cd /src/reply-password | |
parent | 85719154e7412de2d84f64b50b6b98b13981b65f (diff) |
bus: introduce "trusted" bus concept and encode access control in object vtables
Introduces a new concept of "trusted" vs. "untrusted" busses. For the
latter libsystemd-bus will automatically do per-method access control,
for the former all access is automatically granted. Per-method access
control is encoded in the vtables: by default all methods are only
accessible to privileged clients. If the SD_BUS_VTABLE_UNPRIVILEGED flag
is set for a method it is accessible to unprivileged clients too. By
default whether a client is privileged is determined via checking for
its CAP_SYS_ADMIN capability, but this can be altered via the
SD_BUS_VTABLE_CAPABILITY() macro that can be ORed into the flags field
of the method.
Writable properties are also subject to SD_BUS_VTABLE_UNPRIVILEGED and
SD_BUS_VTABLE_CAPABILITY() for controlling write access to them. Note
however that read access is unrestricted, as PropertiesChanged messages
might send out the values anyway as an unrestricted broadcast.
By default the system bus is set to "untrusted" and the user bus is
"trusted" since per-method access control on the latter is unnecessary.
On dbus1 busses we check the UID of the caller rather than the
configured capability since the capability cannot be determined without
race. On kdbus the capability is checked if possible from the attached
meta-data of a message and otherwise queried from the sending peer.
This also decorates the vtables of the various daemons we ship with
these flags.
Diffstat (limited to 'src/reply-password')
0 files changed, 0 insertions, 0 deletions