Services4User review

[Nicolas Williams]

On Fri, Sep 04, 2009 at 05:30:21PM -0400, Greg Hudson wrote:
> I should clarify my position:
> 
>   * I am fine with adding unstandardized GSSAPI extensions which have a
> well-defined purpose.  (Thus, gss_acquire/add_cred_impersonate_name is
> okay because that's how we do S4U.)

Actually, S4U2Self and Proxy *both* are in the same boat: they can be
used without new gss_*cred*() extentions because in both cases they can
be used solely through the delegated credentials returned by
gss_accept_sec_context().

>   * I am fine with adding standardized GSSAPI extensions which we don't
> have an identified need for, if resources are available to do so.  For
> example, I don't know if we have a current use for gss_store_cred, but I
> wouldn't think to raise any objection on principle if someone wanted to
> implement it in our tree.

Login daemons like sshd and ftpd can use it (in Solaris sshd uses it).

>   * I see no benefit in adding unstandardized APIs for no particular
> reason, nor do I see any benefit in standardizing
> gss_acquire/add_cred_impersonate_cred.

What's the difference between "for no particular reason" and "[for]
which we don't have an identified need"?  It must be subtle :)

I don't have a current use for these extensions, therefore I won't mind
if they go.  But I can imagine uses for these (think of a PAM module
that uses host and user creds to impersonate the user to other
services).  Typically one has no need for such a thing because the PAM
module will be running with all privileges and it can assert any ID to
any other service on the same host.  But suppose now that you want to be
able to convey KDC-issued authz-data for that user to those other
services; suddenly these APIs become useful!

Sometimes no use will materialize for an API if no one knows about it.
That's where the utility of "experimental" interface classifications
comes.  Experimental C interfaces are best segregated into a separate
shared object, so that their use is easy to identify.  This might be a
good time to figure out how experimental interfaces should be dealt with
by MIT krb5, if at all.

>   * When I said "code that isn't tested doesn't work," I meant that code
> without an identifiable need is likely to bitrot or simply be non-useful
> in the first place, even if it's covered by a regression test suite.

I think one can build tests for these interfaces that prevent bitrot.
In this case you'd build two services: one to get delegated S4U2* creds
and use them to call to the second service.  To test the new credentials
functions you'd use a test utility that calls that second service.  If
the second service can tell the difference, then you have bitrot.

Like I said, the interfaces were there for completeness.  It was
possible that someone might come up with a use for them in review, for
example.  They need not be committed.  They should be written up
somewhere, in case someone would have a use for them if only they knew
about them.

Nico
--