Session Management Proposal

[George]

On Sun, Jan 04, 2004 at 04:51:02AM +0100, Oswald Buddenhagen wrote:
> > Maybe that's why I did it this way originally, I can't remember :) OK,
> > must do authentication using cookies then.  Oh well.
> >
> hmm, i researched the topic a bit, and i think we're lucky. there are
> several solutions:
> - put every socket in an own directory. the dir's permissions _are_
>   honored.
>   not sure whether this ugly hack should be done on all systems (for
>   symmetry) or only on those that need it.
>   the file system structure i have in mind is:
>   /var/run/dmctl/{global,<disp1>,<disp2>,...}[/socket]
> - some BSDs have LOCAL_CRED to identify the peer
> - some systems (BSD-lookalike) can send SCM_CREDENTIALS via cmsg; those
>   credentials are kernel-checked, so can be used to identify the peer as
>   well
> the two latter solutions have the advantage, that they get away with just
> one socket. not sure all systems we want to support support it, though.
> also, the last one is more complex protocol-wise and both require
> hand-crafting the permission checking code (what, on the bright side,
> gives us additional flexibility (whatever we might need it for)).

But doing different solutions for different systems means lots of special
case code both inside the dm's and inside the client code.  If the directory
thing works on all systems, I'd just use that.  It may not be the nicest
solution, but if it's a portable one, it's good enough.  I mean how many
sockets you need to create?  You only need to create one main socket for the
unauthenticated stuff, and then one socket per console display.  There is no
need to create sockets for remote displays, at least not with anything we do
currently I don't think, all the stuff that we need auth for is console only.
Though perhaps in the future we might allow some stuff for remote displays
and we may want authentication there, and on large systems using XDMCP this
could become a LOT of sockets.

On the other hand, perhaps doing the 1 socket, authentication solution is
simpler overall.  The BSD stuff could be used INSTEAD of the MIT cookie
authentication if available.  Still you have to have the MIT cookie code
there for systems that don't support the credentials stuff.  So I don't think
there's much advantage of doing that.  The MIT cookie can be always created
even in addition to other auth methods for the X server.  Given that one
really doesn't gain much from other methods (passwords can be snooped anyway
no matter what X auth you are using if you're not encrypting the traffic), I
don't think it even makes much sense to use anything but the mit cookie auth
for the X connection too.  If at some point we don't support mit cookie for
the X server, we can write the cookie to something like
"/tmp/.dm_cookies/<username>" which would be owned by the user and used for
authentication on the dm socket.

> > Could we add to the spec that authors of such systems should be
> > ritualistically tortured and pictures posted on slashdot?
> > 
> i'm much in favor of this regardless of possible workarounds. :)
> 
> i'll take care of writing a spec; feel free to ping me vigorously if you
> don't see anything in, say, two weeks.

Next school quarter is starting on monday for me, but hopefully I'll have
enough time for vigorously pinging you :)

George

-- 
George <jirka at 5z.com>
   Originality is undetected plagiarism.
                       -- Dean W. R. Inge