Jesse I Pollard - CONTRACTOR wrote:
Paul Klissner wrote:
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
I'm not sure why you say that? The Xdpy number will be whatever it
is for the X display session that the pcscd instance is running in.
It is valid to have other numbers - :1
Sure, Sun Ray uses X display values that start at :2 (by convention,
so as not to clobber one or two heads that may be in the server
itself).
ssh will create one using the convention :10 for the first, :11 for
the second.
Well, anything starting an X server will have to know about other
X server instances on the box, so I imagine that ssh will not create
a :10 if there is already an X server running as :10. If it does,
then that's a bug in ssh (and any other utility that does stuff like
that).
Why would ssh create an X display? Does it also start an X server
using that display number?
Each appears to be a localhost connection, because it really is...
The simulated server just forwards connections to a remote.
Oh, so ssh is creating a proxy that forwards X protocol to the
remote system then? Well, for the purposes of this discussion
then, the ssh X proxy server would be considered an X server,
even though the actual X server is on another machine.
We're not trying to solve the off-machine PC/SC problem, and in
our scheme, we wouldn't by default start an instance of pcscd
for anything but the system console X server and Sun Ray X servers.
Nothing would prevent someone from hacking up the startup scripts
to start a pcscd instance on other X displays (or X proxies), but
that's out of the scope of this project.
Also, I'm not sure that passing around raw APDUs over the network
is really a good idea - shouldn't smartcards be abstracted at a
much higher level such as cryptographic resources and tokens,
file systems, that kind of thing? We generally don't do things
like export raw disk partitions and raw shared memory segments
of frame buffers over the network, we provide hi-level abstractions
for those types of system resources.
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).
This sounds like a corner case that someone has to go out of their
way to mis-configure stuff to cause it to occur, and if there is a
race condition between something like ssh's X proxy and the real
X server on the box, then that's a bug in how the two of them
try to compete for the shared resource of display value :0. X has
never played well with anything but itself at the server level. The
MIT guys just never seemed to provide a good mechanism to control
the creation of and the monitoring of X server instances. The way
that CDE does it is extremely hackneyed and has potential for race
conditions as well.
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.
Sure, but the user/administrator need to fix whatever configuration
is allowing something like ssh to grab :0 - I don't think that this
is a common use case.
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.
How does the issue of which socket the X server uses affect this
discussion concerning pcscd?
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.
This is really a degenerate case. Anyone can misconfigure a system to
do all kinds of weird and stupid things. If someone decides to proxy
display :0 when there is a console that expects to be on :0, then
they probably shouldn't be given the root password, or they are trying
to subvert the system.
It's kind of like saying that I can setup a script in /etc/rd2.d that
will scribble random data over the raw disk partition where the root
filesystem lives.
mike
--
[EMAIL PROTECTED] Sun Ray Product Engineering
I don't speak for my employer. My opinions are not necessarily those of
Sun Microsystems, Inc. or any of its wholly-owned subsidiaries.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
