D-Bus service activation and access control

[David Sommerseth]

On 28/07/17 17:56, Thiago Macieira wrote:
> On Friday, 28 July 2017 04:16:21 PDT David Sommerseth wrote:
>> What I wonder is if the session manager, being started via D-Bus
>> activation, can it connect to a user's session bus?
> 
> It cannot. It doesn't even know the path and the user's session bus daemon 
> would reject the connection anyway for having the wrong UID.

Good, that's makes sense.

>> ** If system/session bus mixture approach is not viable
>>
>> For user specific configurations, could one alternative approach be to
>> make use of the GCredentials API and "tag" configurations to a specific
>> user on the configuration object ... and deny access if an invalid
>> (read: unexpected) user attempts to access the configuration object?
> 
> Sounds like a good approach, though I have no idea what GCredentials is (I 
> assume something from glib).

Good!  Yes, GCredentials is glib/gdbus APIs used for user information.

>> And will this work when the session manager is activated on the system
>> bus by one user and accessed by another user?  It is the session manager
>> which connects to the configuration manager when retrieving the
>> configuration data.
> 
> It will work because any system bus process specifies which user it runs under 
> in its .service file. Your manager will not use either user's UID, but one that 
> you choose.

Wonderful!

>> ** Providing arguments to the D-Bus activated service
>>
>> Is it possible to provide arguments during the activation of a service?
> 
> As in command-line parameters? Yes, they come from the .service file.

Command line arguments, or environment variables.  It cannot be passed
on via the .service file, as the token is unique per VPN client connection.

One detail I forgot to mention.  There exists only one configuration
manager process and one session manager process.  But the single session
manager process need to manage multiple VPN client processes; which
needs to account for multiple users as well as "system accounts" - where
tunnels may be started automatically during the system boot.

>> If the backends process could get the token value it needs to register
>> with the session manager, the backend client process could also be D-Bus
>> activated, with User=root.  The token value does not need to be
>> transported as a command line argument, the communication channel is not
>> important in this case.
> 
> You can't pass tokens from D-Bus to the command-line. But the activation 
> itself is (usually) a method call, which means you can pass that token in 
> arguments to the call that is activating the service.

Ah, right.  But what if the session manager (which is responsible for
starting new VPN client processes) is asked to start 2 tunnels in
parallel by two independent users?  What happens?  I've read some places
that D-Bus serializes these calls.  But will two client processes be
started?  If I've understood the activation concept correctly, only the
first call will result in a process being started.

So if my understanding is correct ... I would need a "helper service"
which is started by activation, retrieves the token value via the D-Bus
method call and fork() + execve() the real VPN client service.

The question will then be, what is best of doing that?  Through a
"helper service" or using pkexec with a polkit policy attached.  What is
the pro and cons for these alternatives?


-- 
kind regards,

David Sommerseth