ConsoleKit, PolicyKit, HAL, XDG_SESSION_COOKIE
stef at bononline.nl
Fri Jul 23 04:27:54 PDT 2010
On 07/23/2010 04:30 AM, Lennart Poettering wrote:
> On Thu, 22.07.10 21:39, Stef Bon (stef at bononline.nl) wrote:
>>> I think the XDG_SESSION_COOKIE should go away and be replaced by the
>>> audit session id as maintained by the kernel, which however has slightly
>>> different semantics.
>> Why do you think that?
> Because it is sufficient to maintain one session cookie/id. There's no
> need to maintain a number of them.
> Also, the current XDG_SESSION_COOKIE has really strange semantics right
> now, because polkit reads it from /proc/$PID/environment. This breaks
> when setproctitle is used. Also, it's not trustable
> information. Everybody can just creat his own random session if he feels
> like it. Since this id is supposed to be used for policy this is a bit
I totally agree that the use of more than one session id is not a smart
Years ago I started a discussion on the udev maillist about this topic,
why not using
one session id when there are two (one for dbus session and one for
The answer I got was that the session id used by dbus was better. Period.
Redundancy is always bad.
And, the link with the X server (the DISPLAY number) is not smart. The
DISPLAY is an
(yes important but not more than that) property of a session, and making
the dbus depend
on this issue will simply rule out other sessions (non graphic login
Session id? I do not have that in proc. Do I have to enable something in
(already enabled audit support)
I guess the Process ID namespace support.
I'm developing a simple construction based on the at daemon to be used
by the udev daemon,
to launch scripts. You know udev should not run scripts self, now this
construction does that.
It's part of my construction to create easy access to all kinds of
resources (local and remote)
to the user, using:
- ConsoleKit to make it session aware
- autofs to have a (auto)mount facility
- udev for detection of local hardware
- various detection tools (openslp, nbtscan, smbclient for finding
- at daemon with extra scripts to launch when requested (at this moment
I did not find anything else....)
- a fuse module fuse-workspace-ll to provide smooth access for the user.
The user can just browse everything in an very userfriendly way.
At the same time this fs provides system information to the
about the underlying fs, is it remote or not, if remote what fs is used,
is locking supported, etc.
The name for the overall construction is mount.md5key.
It's comparable with Gnome VFS, but mine works on the filesystem level,
and does not depend
on the environment. I can browse the network using mc, my favourite
I'm working on my own on this construction, and am planning to give a
I'm planning to publish all the sources at gitorious.
Not working: inotify yet, and pretty difficult. But sooner or later we
will address this too.
BTW I'll see you probably next week at guadec. I saw you will do a
More information about the dbus