Connection to dbus in a new network namespace

[Julian Thomé]

Hello Mailing List,

it's me again ;-)

I'm currently programming on a pam module, which opens a new network
context if a user logs in.

This is done with the unshare() syscall.
 >> http://linux.die.net/man/2/unshare

After this call there is a
	* root network namespace
	and a
	* child network namespace


Because of the unix domain socket network isolation there are proxies
for stream and datagram sockets.
The proxies are started after the unshare is done.

I have written a deamon, too - which receives connection request and
passes filedescriptors back to the requestors.
The daemon runs in root network namespace. The connection between a
proxy and this daemon is done before the unshare syscall.

A workflow is f.e. as follows:

(0) fdpd (file descriptor passing daemon) is started (root ns)
(1) The stream proxy connects to fdpd (root ns)
=================unshare()=====================================
(2) The stream proxy creates a listen socket an makes a bind mount to
/var/run/dbus/system_bus_socket. This is required because the original
socket is still visible in the filesystem. Therefore the unshare-flag
CLONE_NEWNS is also set.
(3) A process wants to connect to dbus in child ns.
(4) The stream proxy (child ns) accepted it and requests a connection to
/var/run/dbus/system_bus_socket from fdpd.
(5) fdpd (root ns) handles the request by connecting to the requested
socket and passes it back to proxy. The connection is done in a forked
child process because the euid has to be changed (seteuid()).
(6) The stream proxy receives the fd. It forwards the traffic between
the fd of the process which connects to it and the fd which was passed
by fdpd.


The basic functionality already works. I can login (tested with gnome
and kde) and listen to dbus (dbus-monitor --system) or f.e. write
something into syslog.

The problem is if want to mount something - an usb device f.e. .
ConsoleKit tries to obtain the XDG_SESSION_COOKIE, of the process (by
reading /proc/<pid>/environ) which established the connection to dbus.
But as decribed in the workflow above - this process doesn't exist
anymore (forked child from fdpd).

So i have written a little workaround by creating a dummy process in
root ns. For each session a dummy process is started (from fdpd) which
handles all requested dbus connections (per session). That means that a
dbus-connection request is forwarded from the fdpd to this dummy deamon.
This dummy daemon runs as long as the proxy do and is started with the
valid XDG_SESSION_COOKIE as environment variable.

I have written several methods to obtain the XDG_SESSION_COOKIE for the
initial call of this dummy daemon.
	* As pam environment: This method is used to obtain the cookie
	as pam environment variable and can be used in association
	with the pam_ck_connector module.
	* As process environment: This is possible with gdm 2.2 f.e.
	because the XDG_SESSION_COOKIE is already setted for the
	procs who wants to connect to dbus.


With gdm 2.2 this workaround works (using the "as process environment
method" - i can mount usb devices in the child ns. But that doesn't no
longer work with gdm 2.3.
gdm seems to set the cookie later on. Therefore i thought it should be
possible to set it with the pam_ck_connector. I do so and read the
cookie with the "get as pam environment" method but that doesn't work
because gdm seems to start a new session by itself - the cookies read
out with the running gdm session differs from the one setted by
pam_ck_connector.


As described above the central problem is the readout of the
XDG_SESSION_COOKIE. Perhaps there is another way to obtain it with gdm
2.3. ?

I descriped the whole "life of suffering" ;-) because perhaps somebody
has a hint, a suggestion for improvement or can tell me another way to
obtain the XDG_SESSION_COOKIE before a window manager has started.

Thank you very much
  Julian



		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de