(A+) Re: [Muscle] Would like to find ideal err const to return in pcsc-lite

[Paul Klissner]

Ooops -- Sorry!  Didn't mean to reply-all to the list. -p

Paul Klissner wrote:
> Michael Bender wrote:
>> 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
>>
> 
> _______________________________________________
> Muscle mailing list
> Muscle at lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle