Hello, I just downloaded pcsclite 1.3.1. I hit a problem when running a program which calling SCardReleaseContext in a different thread. The program has two threads running. Thread one calls SCardEstablishContext and listens on the card events, while thread two calls SCardReleaseContext(). Thread two hangs in SCardReleaseContext().
I checked the source code. It is actually hanging waiting for the lock SYS_MutexLock(psContextMap[dwContextIndex].mMutex); This is in SCardReleaseContext() in winscard_clnt.c file. Do you think it is related to the topic you were discussing under this title? Thanks, Wei > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:muscle- > [EMAIL PROTECTED] On Behalf Of Damien Sauveron > Sent: Monday, April 03, 2006 8:09 AM > To: MUSCLE > Subject: Re: [Muscle] Why can't a session opened by one thread be closed > byanother? > > Shawn Willden a écrit : > > On Friday 17 February 2006 07:55, Damien Sauveron wrote: > > > >>Shawn Willden a écrit : > >> > >>>If you call SCardEstablishContext from one application thread and then > >>>pass the handle off to another thread which will later call > >>>SCardReleaseContext on it, the release will fail. The implementation > >>>explicitly checks to see that the releasing thread is the same as the > >>>establishing thread. > > > > > >>I had mainly added this check for security reason (against a malicious > >>program that wanted perturb the behaviour of a client -- perhaps it is > >>not a very important problem) > > > > > > Hmm. I'm also not sure how much of a problem this is, but I don't think > the > > thread ID check solves it, because the check is performed on the client > > side, i.e. on the side controlled by the attacker. If I wanted to mess > with > > a client's connections to the server, I could simply compile my own > > libpcsclite that omits the client-side thread ID check. > > > > However, unless I'm missing something, I think the server actually > prevents > > such rogue clients. Since each ContextThread listens on a single socket > and > > is associated with a single psContext array entry, I don't see how a > rogue > > app could release another app's context -- not without somehow managing > first > > to break in on the legit app's socket connection. Is it possible to > hijack > > another process's file descriptor? It better not be. Even if it were > > possible, the rogue would also have to know the correct hContext value. > The > > space of hContexts is small enough that it could be searched pretty > easily, > > so if I'm missing something and this attack could be performed on the > code > > as-is, another simple solution would be to enlarge the space of > hContexts, a > > least to the full range of an unsigned long and perhaps even to a larger > > value. > > > > In sum, it appears to me that the thread ID check is a non-solution to a > > problem that is probably already solved. > > > > Am I missing something? > You are right! I have not checked in the code but if I remember you are > right. > Sorry for the delay of my answer but I have a lot of work. > > Thanks for your contributions to pcsc-lite. > > Best regards, > -- > Damien Sauveron > http://damien.sauveron.free.fr/ > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
