Subject: Re: Pluggable GSSAPI

From: "David Leonard" <[email-masked]>
Date: Tue, 01 May 2007 16:00:46 +1000

Martin Rex wrote:
>Tom Yu wrote:
>>The answer to this question determines whether a mechanism has a good
>>way to decide when to garbage-collect dynamic state associated with a
>>minor_status value.
>>    
>
>While a minor_status text containing dynamic situation-specific information
>might be helpful in a small number of situations, it is quite possible
>for gssapi mechanisms to get along just fine with a 32-bit flat integer
>and no dynamic resources whatsoever.
> 
>With GSS-API v2 I see no other possibility than to use a (ring) buffer
>for a small number of past errors, potentially thread-local if that
>is an issue.  I've seen implementations doing this and it worked well.
>If the only thing that's being done is to echo back the entire
>offending input parameter, then I don't really see the need.
>
>  
Isn't jolding messages in a ring buffer just pushing the problem into a 
smaller, but still dynamic allocator? Mechanism error messages are most 
useful when they contain specific information, such as the input 
parameters perhaps (but more usually a configured filename or setting) 
and that means dynamically allocated strings.

You're right that minor_status codes don't need to be exposed to an 
application if all you want is the display text. Good riddance to 
minor_status integers, I say!

I'm in two minds about Nico's idea of using the existing pointers as an 
app context. I call it gssapi v2.5 and it's a bit like a durian. Smells 
bad, but satisfying. I find it attractive because of the 
usable-and-workable-right-now aspect, and appalling because it's a hack. 
Unless gssapiv3 has something amazing, I reckon use of v2.5 will be 
effective and could hamper adoption of v3.

The complaints against pursuing an OO influence on the GSSAPI are 
interesting. I didn't intend to suggest that we allow subclassing of the 
gssapi and let dependencies get out of hand like the gtk+ example. It's 
a good warning sign, but my stand is completely the opposite: I'd like 
to see a flexible control channel between the application and mechanism 
implementations so we can avoid existing dependencies like 
gss_krb5_copy_ccache(). Returning to the OO influence idea, I mean 
moving global state into managed entities (e.g. app contexts), and then 
re-thinking the GSSAPI functions as methods on those entities.

There is already a de facto mapping from the GSSAPI to an ABI so I don't 
think we need to worry too much about that. I'm not even sure how a 
standard ABI could be drafted.

d
-- 
David Leonard
Resource Central software engineer
Quest Software; 303 Adelaide St, Brisbane, Australia; www.quest.com
Phone: (US) +1 801 655 2755  (AU) +61 7 3023 5133 

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 1 May 2007 10:33:54 -0500

> effective and could hamper adoption of v3.

I'm one of those few people outside Malaysia who likes Durian.  That
might explain it.

Nico
--

---

From: Michael B Allen <[email-masked]>
Date: Tue, 1 May 2007 16:45:01 -0400

On Tue, 01 May 2007 16:00:46 +1000

> re-thinking the GSSAPI functions as methods on those entities.

I don't really think that using a context "object" to hold and abstract
state and calling functions methods is object orientated programming. To
have object orientation you need polymorphism and there is no polymorphism
in my example.

The API I am pitching just uses a single stateful context to hold and
abstract the state of authentication, options, parameters or anything
that would otherwise be scattered about and passed to functions that
take 10 parameters.

As a programmer, it is my experience that the organisation of state used
by the krb5_* and ldap_* apis is easier to use and more flexible than
other techniques.

The procedures and semantics of abstract GSSAPI routines would not change.

If anyone feels like this is worth exploring let me know and I'll look
into it. I am curious to know if it could be constructed as a stub on
top of an existing implementation.

Mike