gdbus - caller authentication
Simon McVittie
smcv at collabora.com
Tue Aug 29 09:17:57 UTC 2017
On Mon, 21 Aug 2017 at 18:20:51 +0200, David Sommerseth wrote:
> Currently I use g_bus_get_sync() to get access to the system bus and
> when I call g_dbus_connection_get_peer_credentials () from the service
> side, it returns NULL. So I believe something needs to be flagged
> correctly to provide that information.
You cannot use g_dbus_connection_get_peer_credentials() as a client of
the dbus-daemon. The client authenticates itself to the server; the
server does not authenticate itself to the client (the client just
assumes that the D-Bus address it was given, either via explicit API
calls, environment variables or hard-coded defaults, was obtained in
some trustworthy way).
Even if the authentication was bidirectional,
g_dbus_connection_get_peer_credentials() would be the wrong thing for
your use case, because it would always return the uid/pid of the
dbus-daemon itself, and not the message sender. (Look at its API and
ask yourself: how could this function possibly know which other
connection I want to know about?)
To get the credentials of another connection to the same dbus-daemon,
call the org.freedesktop.DBus.GetConnectionCredentials() method or a
higher-level API that wraps it. The *sender* of a D-Bus method call
message is a suitable parameter to pass to GetConnectionCredentials.
> I have also started to wonder if this should be handled by polkit as
> well, but I haven't fully grasped the concept of how that could be done.
> Part of it would be the policies, which I don't quite understand how it
> could check if the method caller to the D-Bus server could be matched
> against a stored value inside the configuration manager. So then some
> of the authentication would need to be passed on from polkit to the
> configuration manager.
When using polkit, I think the typical pattern would be to compare
the sender's credentials with credentials that you previously stored
(the "owner" of that VPN configuration), and ask polkit about a
different *action*. For example, if your project's domain name is
OpenVPN.example.com, you might define actions
com.example.OpenVPN.create-configuration (which might be allowed for
everyone by default), com.example.OpenVPN.modify-same-user-configuration
(which might be allowed for everyone by default), and
com.example.OpenVPN.modify-other-user-configuration (which might only
be allowed for root-equivalent users, *admins* in polkit terminology,
by default). UDisks2/storaged do similar things when they distinguish
between removable disks attached to the same seat where the requesting
user is logged-in, and removable disks attached to a different seat.
S
More information about the dbus
mailing list