On 10/31/2013 05:56 PM, Schaufler, Casey wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Jacek Janczyk >> Sent: Thursday, October 31, 2013 4:26 AM >> To: Tizen Dev >> Cc: 'Semun Lee' >> Subject: [Dev] [RFC] kdbus transport for DBus >> >> Dears, >> >> Here, at Samsung, we are experimenting with product specific DBus >> extension to use kdbus (kernel module) as a transport layer instead of Unix >> sockets. >> Currently the scope is limited to enable applications using either libdbus or >> glib (libgio) to work on top of kdbus bus without noticing any difference. >> More one can find in a brief arch description attached to modified dbus >> sources (see doc-kdbus directory). In the same place there is also a current >> development status. We will add there also our todo list. > > What is your plan regarding supporting Smack? If you do not support Smack > controls in kdbus it can not be used in Tizen. > > Really. That's a day one requirement.
By default kdbus provides us with rather different security model compared to what we had before (with modified dbus-daemon). Namely, when client app connects to bus it can request kdbus to attach security context[1][2] of source application to each message it delivers[3]. This moves the need to check permissions from entity that does the routing (previously dbus-daemon, now kdbus) to client application itself (effectively binding libraries). Iff this model is acceptable for us then all we have to do is to add policy checks to respective binding libs. If not - we would probably need extend kdbus to support security label-based policing/routing (as HyungJun wrote we've started looking into it). [1] https://github.com/gregkh/kdbus/blob/master/kdbus.h#L235 [2] https://github.com/gregkh/kdbus/blob/master/connection.c#L850 [3] https://github.com/gregkh/kdbus/blob/master/message.c#L614 Cheers Karol _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
