Thread: [Perlgssapi-developer] Patches for perl-GSSAPI
Brought to you by:
achimgrolms
Menu
▾
▴
perlgssapi-developer
|
From: Simon W. <sx...@in...> - 2006-04-21 08:04:10
Attachments:
GSSAPI-sxwfixes.patch
GSSAPI-ccachecode.patch
|
I've attached some patches to perl-GSSAPI which we've been sitting on locally for a while. The first fixes a couple of problems we were seeing where buffers would have the final character incorrectly removed from them. The second adds support for a copy_ccache routine to extract the GSSAPI credentials as a krb5 ccache. Hope these are of use! Cheers, Simon |
|
From: Simon W. <sx...@in...> - 2006-04-21 10:11:12
|
On Fri, 21 Apr 2006, Achim Grolms wrote: > +require AutoLoader; This probably isn't required anymore. > - SvCUR_set($arg, $var.length-1); > + SvCUR_set($arg, $var.length); > > Is there a way to write a test that shows the buggy bahaviour? > I want to add that test to the testsuite to see that the changes fix the bug. I'll try and dig something out. It's a long time since I wrote this code, and since then it has 'just worked' for us. > #-------------------------------------------------------- > 3. > gss_krb5_copy_ccache > > Is this function exported by all the GSSAPI implementations? > (Heimdal, MIT, VAS)? It's certainly in Heimdal and MIT. Not sure about VAS. You only really need it if you're writing something that accepts incoming GSSAPI connections - we use it for a couple of servers which carry out delegated actions on behalf of the user. > I am worried to add code the makes the module implementation-dependend, > My idea was to rely only to things defined in RFC2744. Nico Williams has an Internet-Draft which defines a different means of doing this, which hopefully will become part of some future revison of RFC2744 - it's a fairly widely accepted limitation of the current GSSAPI. Cheers, Simon. |
|
From: Achim G. <ac...@gr...> - 2006-04-21 10:44:02
|
On Friday 21 April 2006 12:10, Simon Wilkinson wrote: > > I am worried to add code the makes the module implementation-dependend, > > My idea was to rely only to things defined in RFC2744. > > Nico Williams has an Internet-Draft which defines a different means of > doing this, which hopefully will become part of some future revison of > RFC2744 - it's a fairly widely accepted limitation of the current > GSSAPI. OK,=20 I think David Leonard can answer the question what is supported by VAS. But another point: My idea was to make GSSAPI.pm implementaion-independent (Means regardless o= f=20 which implementation is used - it's transparent from the Perl-users point o= f=20 view). But the patch makes GSSAPI dependent to Authen::Krb5. And Authen::Krb5 depends to MIT Kerberos (and has no Heimdal support). =46rom my point of view that breaks the implementation-independency. Is my thinking wrong? Thank you, Achim |
|
From: Simon W. <sx...@in...> - 2006-04-21 10:47:44
|
On Fri, 21 Apr 2006, Achim Grolms wrote: > My idea was to make GSSAPI.pm implementaion-independent (Means regardless of > which implementation is used - it's transparent from the Perl-users point of > view). > > But the patch makes GSSAPI dependent to Authen::Krb5. Ah yes, indeed it does. > And Authen::Krb5 depends to MIT Kerberos (and has no Heimdal support). > From my point of view that breaks the implementation-independency. > Is my thinking wrong? No, its not. I think I need to come up with another way of exposing this functionality. I'll have a think, and get back to you. Cheers, Simon. |
|
From: Achim G. <ac...@gr...> - 2006-04-21 11:12:34
|
On Friday 21 April 2006 12:47, Simon Wilkinson wrote: > On Fri, 21 Apr 2006, Achim Grolms wrote: > I think I need to come up with another way of exposing > this functionality. I'll have a think, and get back to you. Maybe putting all - GSSAPI.pm (mine, implemetationindependent) dependent - and KRB5 dependent stuff into a separate Module (yours)(like "GSSAPI::KRB5") is a solution? So people who need can get the functionality from CPAN by using the separate module, but the core GSSAPI.pm module is still implementation-independent? Achim |
|
From: Leif J. <le...@it...> - 2006-04-21 13:33:32
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ---------------------------------------------------- >> 3. >> gss_krb5_copy_ccache >> >> Is this function exported by all the GSSAPI implementations? >> (Heimdal, MIT, VAS)? > > It's certainly in Heimdal and MIT. Not sure about VAS. You only really > need it if you're writing something that accepts incoming GSSAPI > connections - we use it for a couple of servers which carry out > delegated actions on behalf of the user. > Actually you should use gssapi credentials forwarding instead. The only time you would need to extract a krb5 cache (which you magically happen to know is there) is for AFS, which I guess is your usecase :-) Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESN8c8Jx8FtbMZncRAk80AKCnj42gmqOA2V1jt5y3ETYd0uTyfQCfafhd KyZKnUhBlr8y4TyUbp4P+HM= =wTRG -----END PGP SIGNATURE----- |
|
From: Simon W. <sx...@in...> - 2006-04-21 13:48:22
|
On Fri, 21 Apr 2006, Leif Johansson wrote: > Actually you should use gssapi credentials forwarding instead. The only > time you would need to extract a krb5 cache (which you magically happen > to know is there) is for AFS, which I guess is your usecase :-) No, GSSAPI credentials forwarding doesn't do what you want. When you accept a GSSAPI context, you get a GSSAPI credentials structure containing the delegated credentials. If you want to save this out to disk so that it can be used by other programs, you need to convert that into a Kerberos structure (or a different mechanisms specific representation, if you're using a different mech), and then use an API specifc to your mechanism to store it. [ Can you take a forwarded credential from gss_accept_sec_context and stuff it into gss_init_sec_context? I guess you can, but I've never tried ... ] Delegating credentials in OpenSSH is the classic (non-perl) use case for this, but it applies for any service which needs to make delegated credentials available to other processes it invokes on behalf of the user. We current use it in a remote file editing system which prods other database services such as LDAP to make updates. All of this happens in different processes - so credentials which are held soley in memory are no use. Cheers, Simon. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X