Jesse I Pollard wrote:
Michael Bender wrote:
I'd like to add SCARD_E_INVALID_DISPLAY to the list of err consts
in PCSC/pcsclite.h [...]
Are the list of error/status return codes controlled by the PC/SC
specification itself, so that we are not really at liberty to add
or change codes as we like, or is there not such a tight binding
between what PC/SC-lite and the PC/SC specification for the client
side API (via libpcsclite.so) provides?
I'm thinking of this specific case where we introduce a new error
code, but no applications know about it, so no one uses it, so that
in effect it doesn't provide any additional value?
Hmmm... and how would you determine if the display is invalid?
We're adding PAM support to pcscd so that we don't have to solve
the general problem of figuring out if the caller of libpcsclite.so
is authorized to use a particular X display. The criteria that we're
using for our work now is that the value of $DISPLAY from the
environment and the UID of the caller on the library-end of the
socket (or door, or whatever) get handed to a PAM stack and the
modules there are responsible for determining if the passed UID
is allowed to access resources associated with the passed X display.
How that gets determined is specific to the PAM modules and the
X display (or range of X displays). In the case that we are working
on, we are providing a PAM module that knows how to do this for
Sun Ray (Sun's thin client [1]) X displays using Sun Ray-private
interfaces. We're also going to provide a sample PAM module that
gives pcscd the same reader access semantics and access control
as it has today, namely, none :-) so that we don't introduce a
regression.
There might be other credentials that would be important in making
this decision and which could be passed up from libpcsclite.so, got
any suggestions as to what else might be interesting? Or perhaps
we could make it more opaque in the sense that we pass a "blob" of
stuff from the client side, through pcscd, and then into the PAM
stack, and only the PAM modules would understand that "blob",
which might be something like key-value pairs. That's for the
future at any rate, for now, we're doing our prototype with just
the value of $DISPLAY and the UID of the caller.
The other bit of information that may not be clear yet is that we
are starting an instance of pcscd for each X display (i.e. for
each X server) on the system. For Sun Ray, that works perfectly
since we never want a Sun Ray session to have access to any readers
other than the ones that are internal to the unit or connected
via USB to the unit. A Sun Ray session will not get access to
readers connected to the system board, or via some kind of network
attached device, etc... That may not be a model that works for
every environment, however. The code to start up a pcscd instance
for each X display is part of the Sun Ray codebase and won't be
put back to open source, however the compile and runtime hooks in
pcscd and libpcsclite.so will be there and given back to the
community.
Paul is going to send out a diagram that describes this mechanism
and will hopefully clarify some of these issues.
consider the problem of some visualization systems... Muliple graphic
displays are/can be installed in one system.
Two (or more) heads, each with a separate X server...
OK, so far this sounds like a Sun Ray server with multiple Sun Ray
thin clients, each which can have a Sun Ray session that lives in
the context of an X server connected to it.
I can also see this as a desktop system with multiple frame buffers,
each with either a separate X server or perhaps with a single X server
treating each frame buffer as an X screen (i.e. :0.0, :0.1, etc...).
The best bet I can think of currently is to create a new Input module
for the X server. It would be controled/managed by the X server, but not
used for input or output OTHER THAN to direct/redirect/control the data
stream to/from the card reader and the pcsd server.
I think that your proposal assumes a single pcscd instance for the
whole system, whereas our proposal creates a separate pcscd instance
per X display (and hence per X server). Your proposal has the benefit
of allowing access to the same readers from multiple X displays, since
there is only one pcscd instance that controls all the IFD handlers,
and pcscd in that case can do access control from the clients based
on some criteria. I think you're saying that criteria is to use the
standard X access control mechanisms that already work for X clients
and, via a new XINPUT module, interface with pcscd to perform this
access control? Am I close :-)? How about a new XINPUT module that
a PAM module that is executing in the pcscd context talks to so that
we can continue to use PAM to actually control access using a more
extensible mechanism that people can write plug-in PAM modules for?
One of those PAM modules could be the "talk-to-XINPUT-smartcard-module"
PAM module. The bit that we still would have to figure out using the
single pcscd instance per system approach is how to specify which
readers are accessible to which X displays? In the Sun Ray case, it's
easy since we've made the decision that all readers connected to the
Sun Ray thin client belong to the Sun Ray session that is running
under the auspices of a particular X server, and we don't make any
provision to "share" a reader that is on one thin client with anyone
else, nor do we allow thin-client sessions access to readers connected
to the system board or other non-thin-client hardware; such access
can be provided via "helper daemons" that live outside the X server
and pcscd space.
For security purposes, it is normally a VERY good idea to abort the X
server and restart it for the next user.
Sure. In the Sun Ray case, we start one X server to handle login, and
we start a brand-spanking-new X server for each user upon successful
authentication.
This should allow the X login application to slave all input
> (including the card reader) just as it slaves the keyboard
> and mouse.
Well, if you have two truly independent X servers, and one keyboard
and one mouse (connected to the system's PS/2 or USB ports for
example), then only one of the X servers is going to be able to grab
the keyboard and mouse, and the other X server won't have one, unless
you do some special trickery where you can share your input devices
(clone device drivers that allow multiple opens on the same input
device for example).
This would also eliminate the problem of display control (which reader
goes with which graphic head) by allowing the hardware + X server to
determine the matching devices, just like it does for keyboard/mouse.
I don't understand how the hardware + X server determines which input
devices go with which X server instance (in the general case). I know
how that works on Sun Ray - we have a custom DDX that handles input
to the X server, so X server instances, Sun Ray thin clients and input
devices connected to the Sun Ray are all tightly bound via the DDX.
It would also eliminate the problem of a user attaching to the device
without using the X server.
You may want to allow that in some cases though, although right now
I can't think of one that is compelling enough to want to figure out
how to make that work with your proposal :-)!
Just a thought.
This is good conversation, thanks (everyone) for bringing it up. I think
that this area of MUSCLE/pcscd has been sorely ignored for way too long,
and I'm glad to see that we're all starting to think about it more
seriously recently.
mike
[1] http://www.sun.com/sunray
--
[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
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
