ConsoleKit, PolicyKit, HAL, XDG_SESSION_COOKIE

[Stef Bon]

  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
> strange.
Hi,


I totally agree that the use of more than one session id is not a smart 
thing.

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 
ConsoleKit).
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 
for example).

Session id? I do not have that in proc. Do I have to enable something in 
the kernel?
(already enabled audit support)

I guess the Process ID namespace support.


BTW
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 
remote resources)
- 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 
(desktop)environment
about the underlying fs, is it remote or not, if remote what fs is used, 
is locking supported, etc.

Look at:

http://linux.bononline.nl/linux/mount.md5key.new/

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 
editor/filemanager/tool.


I'm working on my own on this construction, and am planning to give a 
presentation about
it soon.
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 
presentation.


Stef Bon
Voorburg