Question about file desriptors.

[Thiago Macieira]

Em Quarta-feira 23 Setembro 2009, às 10:51:56, você escreveu:
> >> Ok, two questions: what's a X11 atom?
> >
> > http://en.wikipedia.org/wiki/X_Window_System_core_protocol#Atoms
> >
> > In case of dbus-launch I think what is meant is a root window property
> > (the name of which is an atom).
> >
> >> And what's so special about it that the dbus-launch program wants
> >> info from it?
> >
> > It is a way to make sure that you have only one session bus per X
> > session, by using the X server (root window) as a registrar.
> 
> Ok, that's making things clear to me.
> 
> Well, to be honest I'm a bit of a purist. I know that everything is
> working now perfectly, but I think that the same things are done here
> more than once.

Right. But since "we were there first", why shouldn't ConsoleKit change 
instead?

> THis atom is as I understand a way to identify the session, unique, 1:1.
> Now I've made some remarks about ConsoleKit. This tool is for
> administration of the seats and sessions. One of the things it does, is
> create a cookie (XDG_SESSION_COOKIE) which is unique to the session,
> also 1:1.

$ echo $XDG_SESSION_COOKIE
399ad382e2320c886143a60046c1d61b-1250260859.207682-1887743815
$ cat /var/lib/dbus/machine-id
399ad382e2320c886143a60046c1d61b
$ date +%s
1253706833

The cookie is formed by concatenating the machine ID, the timestamp (with 
microseconds) and a random integer.

It's supposed to be non-repeatable and also not guessable.

Unlike the CK session ID, the D-Bus session identifier is repeatable and 
guessable. In fact, that's the entire idea. The session isn't identified by a 
shared secret, but by being able to connect to the the same X11 server and 
having the same UID.

> Dbus could also use that one, and also take in account it's a
> x11-display or not, and it's a local or a remote session. This
> information it can also get from CK.
> Then things do not have to be done more than once, and as far I
> understand, the session cookie is THE key to identify the session.

I disagree. And, like I said, "we were there first", so I don't see why we 
should change.

The reason this autostart mechanism exists in the first place is to support D-
Bus enabled applications running on legacy environments that do not start D-
Bus. If we cannot count on them starting D-Bus, we cannot count on them 
opening a session with ConsoleKit either. So we cannot use the 
XDG_SESSION_COOKIE variable.

> Again I know it's working very good now, but I'm very enthousiast about
> Upstart. I think it's a very good tool to start services, and look at
> dependencies when doing so. I also know that Upstart is not in every
> distro available.
> 
> Is this good a good idea?

Not until Upstart is available in most distros as well as (future) legacy 
environments. Until that happens, we cannot rely on it. 

We could start using it for systems where it is available, but we must 
continue to support the existing scheme for the foreseeable future. Given that 
constraint, I don't see the need to further add to the complexity.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14     San Francisco, California: Nov 2 - 4
      http://qt.nokia.com/qtdevdays2009
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090923/a4960564/attachment.pgp