[rfc] The Big Picture

[uwesmail2005-lkml at yahoo.de]

I think it is time to outline a Big Picture Show how the ultimate
Desktop
should work. I hope that this rests some FAQ too.

Boot and login:
upstart starts a (messagebus owned) dbus-daemon with

--system --print-address

then reads that address and connects to it. So upstart punts config of
that address. Then upstart tries to read its config from
'org.freedesktop.Hal'. That would result in an activation request of
o.fd.Hal back to upstart, which upstart gladly handles by starting a
dbd (DataBase Daemon). dbd in turn is a part of what is hald today and
only does save key-value-pairs and emits signals when they change. Some
key-value-pairs affect other keys by restricting who can do what with
them. dbd does *not* read any files. On startup dbd asks for
eg. 'org.freedesktop.DBD_Persistence'. This service will then also be
activated by upstart, and load o.fd.Hal from some backend. Now the read
request for config will succeed. Now upstart starts the configured
services. Every service that succeeds, at least drops its pid into dbd.
The changed-signal of that key triggers the startup of the dependant
services. These changed-signals are the events in upstart parlance. One
of the earliest services that are started is hal-coldplug. This program
is the second part of hal. It traces the hardware-tree and sets the
appropriate keys (that keys that form today the hal data base)
However it does not enhance or modify the keys as the policy in todays
.fdi-files does. That part of hal is hal-policyd. That listens for
value-changed signals from o.fd.Hal and modifies appropriate keys as
policy dictates.
One of the other services is login. Login consists of two
parts: a system daemon that listens for new consoles as they are
entered
      into o.fd.hal or as they are freed by disconnects of their
session
      bus. For every available console the login daemon asks upstart to
      start a session bus for user 'nooneyet'. Then it starts its
second
part: its user interface as user 'nooneyet' and connects to that
session
      bus. After the UI has connected, the system login daemon asks
that
      session bus's connection with the system bus (every session bus
is
      connected to the system bus, if only to track the come and go of
      sessions, and to track which console is active (dbus daemon in
      session mode allows ioctl(VT_GETSTATE) to check for active))
      to addfilter for the signal 'userlogin' from its UI. After an
      user logged in, the UI sends that signal, and waits to be called
      back.
After the system login daemon has obtained the credentials from its UI
counterpart it asks upstart to start a new session bus on that console,
this time for that user, but suid 'messagebus'. That effectively
restricts the user from messing with the session bus daemon
with ptrace() and/or fooling with the connections to the system bus.
That in turn means that the system bus can trust the statements that
the session bus makes about himself. upstart can introduce itself as
sessionmanager in this process to make all started services part of the
same setsid()-session. The startup of the user session is very like the
boot process as outlined above. The dbd is now used to contain user
specific keys like gconf does today.

ATTENTION: The user 'nooneyet' should not be confused with the
           user 'nobody'. Because 'nooneyet' can ask upstart to start
           programs for other users its role is very near root,
           securitywise. But it can do nothing itself and upstart
           decides to grant or deny that request, which makes its
           might highly configurable.

ListActivateableServices:
    should be implemented (and found at) o.fd.upstart
    If not found internally o.fd.upstart should try
    o.fd.upstart.<hostkey> (at least for activation,
    listing could contain a 'see too' marker)

Xserver:
The Xserver is split in a session specific and a hardware specific
part.
The session specific part handles windows,selections,atoms(partly),
properties. The hardware specific part handles drawing,cursor,keyboard
events and emits signals when a pointer (there could be more than one)
crosses a vertical or horizontal line defined by the session specific
part. Only the hardware part runs as root. They communicate by D-Bus
of course.

SSH:
When one sees the description of the login process above, one realizes
that the difference to a privilege separated ssh is very small. There
is
only the socket connection to transfer from system to session part. But
after the login there is a session bus on the start(client) side and
one
on the other (server)side. They must be connected to be one. And ssh
must
play the part of the proxy. For that it must be able to register

new unique names: I propose that any attempt to register an unique name
                  should be answered with an error at the level of the
                  D-Bus library like it is today. BUT any attempt that
                  is made directly to the Bus should be met with a
                  registering of a new unique name that is constructed
                  like
':'<part made from the connection unique name><terminator><part made
reversibly from the requested unique name>.

Then ssh can request for every unique name on the remote session bus
a new unique name on the local session bus and vice versa. And the
well known names are possible to proxy even today.
When ssh faithfully duplicates all messages between the two busses they
will work as one session bus. The only question is what should be done
with well known names already registered on both sides when the
connection is made.
'org.freedesktop.DBus': will be separated, no proxying
'org.freedesktop.SystemBus': (a name the system bus registers on the
                              session bus for session specific access
                              to machine hardware ('at_console'))
                              separated, no proxying
'org.freedesktop.ServerBus': (a name the system bus registers for
                              finding the system level counterparts of
                              privilege separated servers)
                              taken over by proxy, X-Forwarding falls
                              of automatically.
'org.freedesktop.SessionBus':(the name on the session bus where the
                              system bus sends all messages that arrive
                              at the unique name of the session bus
                              on the system bus)
                              normally implemented by the session bus
                              but taken over by proxy
'org.freedesktop.upstart':   (if upstart is session manager)
                              proxy by appending the servers host key
                              as machine id and registering with the
                              real 'org.freedesktop.upstart'
No other names should be registered on the server session bus because
it's fresh.

Machine id:
The SSH Host Key could work as a machine id. There is even a program
in the ssh distribution (ssh-keyscan) that could be used to get this
machine id. I would recommend that the interface of the system level
ssh daemon contains a method that gets the host key.

UserBus:
To get to a real user bus first a UserMachineBus is needed. That is a
dbd process that listens on the system bus for NameOwnerChanged signals
that indicate a newly created session bus. Then it connects to that
session bus. That will succeed only when it is the same user
(the address is contained in the name that is registered on the
system bus). There it registers the (deliberately misleading) name
'org.freedesktop.UserBus'. If that doesn't succeed (because that
name exists) it will connect to the present owner of that name (besides
listening for ValueChanged signals) and synchronize its database with
the algorithm of http://www.ietf.org/rfc/rfc0677.txt which will keep
that database synchronised across all hosts that session spans.
Because one daemon per user and host exists, it is synchronized across
all sessions that cross that host. Now a process, that wants to access
another process of the same user, only needs to create a key with the
message as value to synchronize that message to every host and session
that (now rightly named) UserBus spans. When the message gets to its
destination it will be deleted from that UserBusDB and delivered to the
process waiting for it. That means there have to be keys in the
UserBusDB that record how many Processes are interested in these
messages to avoid filling the data base with messages no one is
interested in (and that aren't deleted therefore).





	

	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de