[AFS3-std] Re: A call for consensus on draft-brashear-afs3-pts-extended-names-07

Douglas E. Engert deengert@anl.gov
Fri, 17 Dec 2010 10:21:28 -0600


The consensus call time period has ended. We have 10 responses with
ready to proceed. But Andrew Deason has brought up one issue
on "Implicit fallback mapping".

Jeffrey Altman has asked about "wildcards patterns in mappings".

The "Implicit fallback mapping" might be easily resolved with a few
words added to the document, and we could proceed with adoption.

The "wildcards patterns in mappings" might need a lot more, discussion,
as I personally can think of these side issue:

  How are wildcards defined? regex? simple "*"?

  In Jeff's example, user/cron/*@REALM would map to user@REALM
  and looks Kerberos specific. How would names from different GSS mechs
  work with patterns? What if the GSS name can contain one of the pattern
  matching characters?

  At sites that to have separate user@REALM and user/cron/hostname@REALM
  principals, do they really want this mapping? Or do users limit access
  from selected hosts using AFS groups and ACLs. I could see some of my crons
  being able to write to selected directories based on the hostname, but not
  touch my dot files.

So I would like to ask Andrew and Jeff in particular if they feel that we
need to add these items to the document?



On 12/16/2010 9:10 PM, Jeffrey Altman wrote:
> On 12/16/2010 5:05 PM, Andrew Deason wrote:
>> On Tue, 07 Dec 2010 13:07:29 -0600
>> "Douglas E. Engert"<deengert@anl.gov>  wrote:
>>
>>> We have a request to proceed with a call for consensus on:
>>>
>>> http://tools.ietf.org/html/draft-brashear-afs3-pts-extended-names-07
>>
>> I really _really_ don't want to hold this up at the 11th hour, and I
>> think this is deserving of consensus, but if one little thing could be
>> clarified for me:
>>
>> I do not think we discuss anywhere the 'implicit fallback mappings'
>> referred to in 7.4.2. AuthNameToIDFallback. I take it this is something
>> we are regarding as implementation-defined and we do not need to discuss
>> what the implicit mappings may be, right?
>
> The implicit mappings referred to are those similar to hard coded
> principal conversions found in the OpenAFS src/rxkad/ticket5.c.  I agree
> that additional text defining "implicit mapping" vs "explicit mapping"
> would be useful with the definition of "implicit mapping" stating that
> it is implementation specific.
>
> On a separate topic, should this specification support wildcard
> patterns.  For example, if an organization has separate user principals
> for per host cron jobs that are meant to have access to AFS as the user,
> should the organization be forced to AddAuthName for all valid
> user/cron/hostname@REALM principals?
>
> Or should we permit a wildcard pattern mapping user/cron/*@REALM ->
> user@REALM?
>
> Should such an example be implemented as site specific implicit mapping?
>
> Thoughts?
>
> I am happy with the document in all other respects.
>
> Jeffrey Altman
>

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444