zondag 25 juli 2010

About dbus_connect_session_bus and dbus_session_domain. (and other interfaces that include the dbus_session_type attribute)

These interfaces currently use the session_bus_type attribute in Fedora.
The problem is that all restricted xwindows and the unconfined users have this attribute assigned to their dbus domain.

Take for example telepathy, which is a framework that is started by dbus session domains. If you use the dbus_session_domain() interface to start telepathy processes, then this means all restricted xwindows and the unconfined users automatically transition to the telepathy domains when they run telepathy programs from their dbus domains.

Same goes for the dbus_connect_session_bus() interface in terms of which process that acquire service to which dbus session domains.

In my branch i went ahead to try and fix this. Instead of using the session_bus_type attribute i use $1_dbusd_t type instead. This way i can define which dbus session can start a program that needs to be started by session dbus domains.

The problem is that the compiler does not like and permit this. You will run into duplicate declaration issues of the dbus session type ($1_dbusd_t).

There is a way out of this but it is an ugly work around: Call the interfaces described above in the same optional policy block as where the dbus_role_role is called from.

By the way: i do not see how dbus can be considered optional.

The end result is that domains started by dbus session domains can not be optional and should be compiled into the base module.

Which programs am i talking about? For starters Gnome. Stuff like Gnome configuration daemon, settings daemon, keyring daemon, VFS daemon etc. Then Telepathy, Empathy, Gnome DVB daemon, Vino and who knows what else.

Also: The dbus_session_bus_client is, in my view, too coarse. It also uses the session_bus_type attribute, allowing the caller to send DBUS messages to all dbus session domains and allowing the caller to stream socket connect to all dbus session domains.

This is what i am currently using for the two interfaces described above (i left other interfaces affected by dbus_session_type in the current state for now)

########################################
##
## Connect to the specified session BUS
## for service (acquire_svc).
##

##
##
## Prefix to be used.
##

##
##
##
## Domain allowed access.
##

##
#
interface(`dbus_connect_session_bus_to',`
gen_require(`
type $1_dbusd_t;
class dbus acquire_svc;
')

allow $2 $1_dbusd_t:dbus acquire_svc;
')

########################################
##
## Allow a application domain to be started
## by the session dbus.
##

##
##
## Domain allowed to transition.
##

##
##
##
## Type to be used as a domain.
##

##
##
##
## Type of the program to be used as an
## entry point to this domain.
##

##
#
interface(`dbus_session_domain',`
gen_require(`
type $1_dbusd_t;
')

domtrans_pattern($1_dbusd_t, $3, $2)

dbus_session_bus_client($2)
dbus_connect_session_bus($2)
')

Moral of this article: I would be nice if we came up with a proper solution for the issues i described.

My branch is "hacked" in a way that it works for a large part but it means that my branch diverged even further from upstream than it already did...

As always: Changes i have made can be reviewed in my Git repository.

4 opmerkingen: