[OpenAFS-devel] Progress on Linux in-kernel RxRPC library

[Jeffrey Hutzelman]

On Tuesday, March 22, 2005 08:40:45 PM -0500 Kyle Moffett 
<mrmacman_g4@mac.com> wrote:

> How about a new socket option "SO_RXRPC_SPLITPORT" or similar,

This sounds sane.



>> So the problem is _almost_ solved.  It just requires one
>> additional constraint, which is that a call made via an
>> unbound socket must not share a connection with a call made
>> via a bound socket.
>
> Or perhaps we should add another option "SO_RXRPC_SHARECONN"
> for outgoing calls that overrides the above constraint when
> all processes involved set it.

That works.  In fact, at the sockets layer I guess I really don't care 
whether the default is to share connections or not, as long as the 
application has the choice.


>>> Well, other models are:
>>> Create a thread to handle a specific connection from a
>>> specific user, including all the RPCs they ever need to
>>> make. Or, create a bunch of worker threads beforehand and
>>> just have them switch keys whenever they need to change
>>> which user they act as.
>>
>> Yeah.  I dunno; forcing what I see as a parameter into what is
>> essentially (thread-)global state just seems wrong to me.
>
> David Howells and I have been discussing whether it would be
> better to specify it per-connection with setsockopt or via a
> search in the keyrings, and while it might be more powerful to
> allow direct specification, it doesn't match as well with the
> idea of a set of "credentials" with which all accesses are
> done.

True, but if you look at existing API's for things like Rx, Kerberos, and 
GSSAPI, an initiator always gets to provide specific credentials to be 
used, with the ticket file or keyring or whatever being used as a fallback 
if it chooses not to do so.  Applications are generally encouraged to use 
the default behaviour when possible, but there will always be exceptions.


> On the other hand, one idea I was just thinking about is to
> allow the user to specify credentials with a setsockopt option
> such that a key id of -1 indicates that it should perform a
> keyring search.

Yes, something along those lines.  It would even be reasonable, I think, to 
do a keyring search by default and do something else only if the caller 
explicitly requests particular credentials.

I would also suggest a separate option to be used to express a preference 
for the type of credentials to be used.  At the moment the choices would 
presumably be { rxnull, Kerberos, ANY, ANY-except-null }, with ANY being 
the default.  In particular, it's useful to be able to make a call without 
authentication even if there are credentials available, and it's fairly 
important to be able to require an authenticated connection, with an error 
if no credentials are available.



> Ideally we should try to come up with the
> cleanest and most expressive API/ABI possible, because anything
> we get merged with _either_ codebase is not likely to be very
> changeable once applied, due to binary compatibility concerns.
> (Unless of course you're talking about kernel-internal ABI,
> which changes whenever somebody thinks they can make it work
> better, which is quite frequently).

True on all counts.

> Maybe in a couple weeks
> or so I'll have a patch for you to look at.

OK.  And maybe some more API details, as they become available?

-- Jeff