Heads up for login managers

[Alan Cox]

On Mon, Feb 12, 2007 at 03:25:03PM -0500, David Zeuthen wrote:
> We need XDG_SESSION_COOKIE to make sure what desktop session a D-Bus
> call originates from. We can't use uid for this because you might be
> logged in multiple times and at different seats. For example; if you're
> inactive at seat A you should not be able to invoke Mount() on HAL on a
> storage device that is exclusive to seat A just because you're active on
> seat B. We can do this securely only with XDG_SESSION_COOKIE. If we used
> uid it wouldn't be secure.

No, you are consistently missing the point here. Let us take you example
step by step

Assertion:
XDG_SESSION_COOKIE allows us to tell session A from session B

On seat A I write my XDG_SESSION_COOKIE to a file and wait for it to go inactive

On seat B I set my XDG_SESSION_COOKIE from the file

Seat A and B processes of mine now have the same cookie so can't be told
apart

On seat B I call Mount() for a storage device on seat A

Assertion false.

A second problem is a single application running on both seat A and seat B
at once under my uid.

Let me suggest an alternative assertion:

Assertion:
uid is sufficient to enforce the desired policy


I propose the following logic

Aceess a a resource tied to seat A is granted only if the caller has the uid 
that is the same as the *active* session on seat A

That is:
	Uid = Uid of inactive session on seat A		-> REFUSE
	Uid = Uid unrelated to a session on seat A	-> REFUSE


Flip it to use kerberos keys (whose posession is controlled by uid and 
external to the system by shared security policy) and it flies sweetly.