pam_pkcs11 chngsets 218 & 219

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

pam_pkcs11 chngsets 218 & 219

Jonsy (teleline)
I'm having problems with eTokenPro 32 pkcs11 "native" (manufacturer
supplied lib): C_Finalize() never returns when C_Initialize() is
called with NULL as parameter

(OpenSC-PKCS11 works fine :)

So chgset 217 was send to allow at compile time change the behaviour
of C_Initialize() and provide an initArg param to use system
native threads

But, after lunch :-) my feeling is that every modern **ix support
native threads, so make it a compile-time option is useless...

Reading mail list this change will make init fail for propossed
patch to opensc-pkcs11 ( return fail on non-null C_Init() arguments )

And AFAIK pam doesn't use threads at all, so I don't really need
compile with "-lpthread"

So I propose make C_Init() arguments to be non-null at configure
time, by adding "support_threads" boolean entry at pkcs11-specific
module entry in configuration file. This means revert yours and
mine previous patch

Any Comments?

Juan Antonio Martinez


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pam_pkcs11 chngsets 218 & 219

Ludovic Rousseau
On 12/12/05, juan antonio martinez <[hidden email]> wrote:
> I'm having problems with eTokenPro 32 pkcs11 "native" (manufacturer
> supplied lib): C_Finalize() never returns when C_Initialize() is
> called with NULL as parameter

So it is a bug in the manufacturer provided token, no?

> So chgset 217 was send to allow at compile time change the behaviour
> of C_Initialize() and provide an initArg param to use system
> native threads

I am not sure you have to use a non NULL_PTR value since you do not
use threads in the PAM module. It is not because the system provides a
thread library that you have to use it.

> And AFAIK pam doesn't use threads at all, so I don't really need
> compile with "-lpthread"

I agree.

> So I propose make C_Init() arguments to be non-null at configure
> time, by adding "support_threads" boolean entry at pkcs11-specific
> module entry in configuration file. This means revert yours and
> mine previous patch

No problem, revert the changes. My 218 & 219 changesets was just to
use threads "correctly". But I agree that pam_pkcs#11 should not use
threads at all. Maybe we will need them in the future...

Bye,

--
  Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: pam_pkcs11 chngsets 218 & 219

Jonsy (teleline)
El lun, 12-12-2005 a las 16:58 +0100, Ludovic Rousseau escribió:
> On 12/12/05, juan antonio martinez <[hidden email]> wrote:
> > I'm having problems with eTokenPro 32 pkcs11 "native" (manufacturer
> > supplied lib): C_Finalize() never returns when C_Initialize() is
> > called with NULL as parameter

> So it is a bug in the manufacturer provided token, no?

Not exactly ... eTokenPRO SDK Manual states that libetpkcs11.so
needs "pcsc-lite >= 1.2.0", so I created a fake link from
libpcsc-lite.so.0 to libpcsclite.so.1 which worked fine...
with mozilla, that doesn't call C_Finalize() as stated
in many mails in this list. But with non-mozilla apps
-those that properly call C_Finalize()- Fail and freeze

Reverting from pcsc-lite-1.2.9b6 to pcsc-lite-1.2.0 C_Finalize()
from Aladdin's propietary pkcs11 lib now works as expected.

I'll write Aladdin to get an up-to-date pkcs11-library,
or even better release it as Free Software :-)

Reading from pam(3) man page:

"No PAM functions are safe to be called by a multithreaded application."

And pam_pkcs11 tools don't use threads at all...

So:
I'll remove pthread issues on pam_pkcs11 source code
And retain last patch to allow run-time option for non-null
parameters on C_Initialize(). Perhaps in the future we'll need it :-)

Juan Antonio

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: pam_pkcs11 chngsets 218 & 219

Ludovic Rousseau
On 12/12/05, juan antonio martinez <[hidden email]> wrote:

> El lun, 12-12-2005 a las 16:58 +0100, Ludovic Rousseau escribió:
> > On 12/12/05, juan antonio martinez <[hidden email]> wrote:
> > > I'm having problems with eTokenPro 32 pkcs11 "native" (manufacturer
> > > supplied lib): C_Finalize() never returns when C_Initialize() is
> > > called with NULL as parameter
>
> > So it is a bug in the manufacturer provided token, no?
>
> Not exactly ... eTokenPRO SDK Manual states that libetpkcs11.so
> needs "pcsc-lite >= 1.2.0", so I created a fake link from
> libpcsc-lite.so.0 to libpcsclite.so.1 which worked fine...
> with mozilla, that doesn't call C_Finalize() as stated
> in many mails in this list. But with non-mozilla apps
> -those that properly call C_Finalize()- Fail and freeze

That's an interesting bug.

pcsc-lite <= 1.2.0 and pcsc-lite >= 1.2.9 should be API compatible
except for SCardControl().

> Reverting from pcsc-lite-1.2.9b6 to pcsc-lite-1.2.0 C_Finalize()
> from Aladdin's propietary pkcs11 lib now works as expected.
>
> I'll write Aladdin to get an up-to-date pkcs11-library,
> or even better release it as Free Software :-)

I strongly suspect the bug to be in Aladdin software but without their
source code I can't be sure.

Bye,

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel