Ludovic Rousseau wrote:
On 19/10/06, Paul Klissner <[EMAIL PROTECTED]> wrote:
The pcsclite library must check the $DISPLAY environment variable
on the client and validate that it refers only to a display, on
the local machine, if defined. Failing that, it needs to return
an error code to the client.
I'd like to add SCARD_E_INVALID_DISPLAY to the list of err consts
in PCSC/pcsclite.h, and the text "Invalid $DISPLAY environment" to
pcsc_stringify_error(), but I am concerned that I might be
constrained by backward-compatibility issues.
Can you describe the backward compatibility issues you are thinking about?
I was cautioned about being constrained by use of the API, wherein
existing applications might check for errors against a specific
fixed list of known return codes that had been spelled out in the docs,
perhaps rather than determining first that there is an error by comparing
the status to SCARD_S_SUCCESS.
Ie. creating a new failure code, it is conceivable that, if the
establish function failed with that error, some applications might not
detect that an error occurred when it first is reported.
That concern might not be a good enough reason to obstruct progress
in extending the error code set. I'm new to this library and unfamiliar
with the proper mindset; trying not to make assumptions.
Any thoughts on this, or which existing error codes I might
fall back to using if extending the list isn't an option?
The existing list of error constants seems far from ideal.
I do not like the name SCARD_E_INVALID_DISPLAY. It could be more
generic like SCARD_E_NO_PERMISSION.
Maybe this error code could also be used to solve the problem
described in the recent thread "Limiting reader access to the console
user only" [1].
The PAM module/stack may help solve that problem as well.
It is easy on the libpcsclite side to check the file permissions of
/var/run/pcscd.pub and return SCARD_E_NO_PERMISSION when appropriate.
You're right. That error code solves more problems. It doesn't address
things like a bad $DISPLAY environment variable format or bad syntax
directly, but those could be indicated by SCARD_E_INVALID_PARAMETER,
which already exists in pcsclite.h, if the docs indicated clearly
that if $DISPLAY is defined, it becomes an indirect parameter.
Also, further validation of the X display is done server side,
where client EUID is obtained from the socket and authenticated
via a PAM module as the owner of the X display. If that check
fails, I planned to return the same error code as for a
client-side failure, however, having an even more explicit
error might be reasonable too.
Why do you have two cases with two (possibly different) error codes?
I think one new error code, the one you suggested, would be ideal.
pcscd currently, as well as our project, require that $DISPLAY,
if defined, refer only to the local host. From the standpoint of
my project that is a security/permission requirement. With pcscd
it is more a 'not-yet-implemented' problem, for which returning
SCARD_E__NO_PERMISSION would be slightly misleading. In that case,
SCARD_E_INVALID_PARAMETER would probably be appropriate to return
if $DISPLAY refers to a non-local host.
Whichever way this goes, I think it is important to document the
use of $DISPLAY in all the right places, such that people realize
that $DISPLAY is an an indirectly referenced input parameter, if it
is defined, so users know to consider it if SCardEstablishContext()
or SCardConnect() calls fail.
> Which PC/SC call would return the two error codes?
> SCardEstablishContext? SCardConnect? another one?
Currently I'm only returning the error from SCardEstablishContext().
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.
Not sure if it should occur in SCardEstablishContext()or SCardConnect().
SCardSetAttrib() calls IFDSetCapabilities(). I wonder if IFDSetCapabilities()
would be the most appropriate way to pass EUID and Xdpy# to an IFD Handler?
I'm not experienced with the library in use at that level yet.
The question there is: How could I use IFDSetCapabilities(), a function
designed to be used with IFD-specific awareness, to pass EUID/Xdpy#
to our IFD Handler from pcscd to avoid having to use a front-end
shim or interposer library?
Otherwise, if I were to attempt to use IFDSetCapabilities() to send
EUID/XDpy# to *all* IFD handlers from pcscd, assuming uninterested
IFD handlers would simply ignore them, then how could the attributes
used to identify those parameters be guaranteed not to conflict with
pre-defined attributes already in use by existing handlers? How could
they be guaranteed not to confuse IFD handlers that may not have been
robustly written?
Any of your thoughts on that would be extremely helpful.
Thanks,
Paul
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
