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. -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
