On Thu, 19 Oct 2006, Paul Klissner wrote:

Ludovic Rousseau wrote:
On 19/10/06, Paul Klissner <[EMAIL PROTECTED]> wrote:
Ludovic Rousseau wrote:
[snip]
But that question does bring me to another question:  I need to find a
good way to pass EUID and Xdpy# to our IFD Handler, in a way that plays
nicely with existing IFD handlers.

Which part will send the EUID and Xdpy# to the IFD handler? The user
application?
What happens if the application says "Hey, I am EUID 0, please give me access"?

We actually only need to convey the Xdpy# to the IFD handler. EUID
doesn't need to be propagated (as I alluded too hastily in my previous
e-mail), since it's purpose is outlived beyond authenticating that
the Xdpy# conveyed IFD handler is owned by the client.

The believe now is we can pass the Xdpy# to the IFD handler safely
using putenv via a single environment variable, since there is a
single pcscd per Sun Ray session/X server.

Thus, for any given  pcscd daemon, there will only be one
releveant Xdpy# that needs to be communicated to the IFD handler.

Assuming that Xdpy number is always :0

It is valid to have other numbers - :1

ssh will create one using the convention :10 for the first, :11 for
the second.

Each appears to be a localhost connection, because it really is...
The simulated server just forwards connections to a remote.

It IS possible to get :0 forwarded. There is a race condition when
xdm aborts a server (the :0 /port 6000 is no longer in use) and starts
a new X server and opens the socket (the :0 /port 6000 in valid use).

Granted it will be evident to the user because it would appear that
the X server (he just logged in on) disapeard, and no evidence of
a new one.

But that would be too late...

There is also the issue of when the X server strictly uses the named
socket in /tmp/.X11-unix/X0 and doesn't use socket 6000.
This would allow a simulated X server to report localhost:0, when
actually it is NOT being used by the X server. Your environment
might prevent this one IF the X server cannot use the named socket.

Paul

_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.

_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Reply via email to