[Dev] Cynara session ID

Patrick Ohly patrick.ohly at intel.com
Fri May 16 08:10:33 GMT 2014


On Fri, 2014-05-16 at 08:58 +0200, José Bollo wrote:
> On gio, 2014-05-15 at 20:22 +0200, Patrick Ohly wrote:
> > On Thu, 2014-05-15 at 17:02 +0000, Schaufler, Casey wrote:
> > > > The problem for a hypothetical, patched dbus-daemon calling Cynara will be
> > > > to identify the session. Probably it will not have enough understanding of the
> > > > D-Bus interfaces that it is asked to protect to provide a meaningful identifier.
> > > 
> > > I don't know what you mean by "identify" the session, but expect that
> > > it would be a matter of configuration. Not necessarily simple configuration,
> > > mind you.
> > 
> > I mean this parameter of cynara_check (from the Wiki):
> > 
> >         client_session - /string/ - identifier of application life or
> >         session. It might be needed for checking access granted for
> >         single session. It is service responsibility to define session
> >         properly, e.g. it can be defined as PID of application process
> >         or service-application connection identifier. libCynara do not
> >         interpret this string - it is just compared to previous ones to
> >         distinguish sessions.
> > 
> > I can image that a modified dbus-daemon can be configured to map a
> > certain interface or certain methods in an interface to certain
> > privileges, but configuring it to somehow create a client_session string
> > for a certain caller is probably going too far. Such functionality is
> > better provided by custom code in the service itself.
> > 
> 
> I share your analysis. It isn't pragmatic to expect that dbus will guess
> the session id.

Note that the custom code also may have problems coming up with a good
session ID. The key problem is that "application session" is a UI and
app concept that the middleware is unaware of.

The PID is not good because it may get reused for different application
sessions, in particular when one long-running process (Crosswalk) sends
requests for different applications. The opposite can also happen: the
same app session involving more than one process.

The service-application connection is specific to the service. Tt's life
time is not necessarily connected to the app session either. Suppose an
app session connects to service A once and to service B several times.
The user interactively grants access for the session each time a request
pops up. It will be confusing that he or she gets asked more often for
service B.

My conclusion is that the "client_session" idea is nice in theory, but
more work will be needed to make it usable in practice, perhaps even
including an API change (for example, making Cynara itself aware of app
sessions instead of expecting services to handle this).

For services which cannot derive a session ID themselves either, moving
the check to dbus-daemon does not loose any functionality. I still think
it is worthwhile investigating.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





More information about the Dev mailing list