[OpenAFS] cross-realm AFS IDs

lamont@scriptkiddie.org lamont@scriptkiddie.org
Mon, 21 Nov 2005 10:57:33 -0800 (PST)


Thanks, sounds like quick and dirty would solve my problem sufficiently 
until the 16-bit issue starts to annoy me or the principals in my MIT KDC 
start breeding...

If (or when) patches exist, I'm willing to test...

On Sun, 20 Nov 2005, Jeffrey Altman wrote:
> The problem you are trying to solve "multiple names from multiple
> sources represent the same identity" is being worked on.  I expect
> that there will be a cheap and dirty solution available in a future
> 1.4 release in the next few months plus a more permanent solution
> in OpenAFS 2.0.
>
> The quick and dirty solution will provide more than a single realm
> which can be considered the same as the local realm with a list of
> exclusion names for which you want to continue treatment as a foreign
> user.
>
> What site in your situation currently do is require the use of
> a modified krb524 daemon that performs name translation.  Public
> distribution of these hacks is very much discouraged.
>
> Jeffrey Altman
>
>
> lamont@scriptkiddie.org wrote:
>>
>> It looks like cross-realm AFS IDs are required to have the group ID of
>> the cross-realm group (system:authuser@realm) in the lower 16-bits of
>> the ID:
>>
>> user id & 0x0000ffff = group id
>>
>> Does this imply that you only get 16-bits of local IDs and 16-bits for
>> each cross-realm realm?
>>
>> What would break if you assigned arbitrary AFS IDs to cross-realm users,
>> particularly in the <= 0x0000ffff ID space?  What expects to be able to
>> take a user id and strip out the group id from it?
>>
>> I've got cross-realm users which are in an AD REALM that I want to use
>> while keeping my cell principal in an MIT KDC.  Those cross-realm users
>> are already in my /etc/passwd file with a globally unique uid that it
>> would simply my life greatly if I could use for an AFS ID.  Also, all
>> the foreign cells that I'll access will have exactly the same mapping of
>> IDs to the AD realm.
>>
>> Is there any way around this, or am I stuck with only 16-bits of
>> 0xnnnnff2e IDs and the need to use some kind of nss_afs to resolve those
>> names with getpwuid()?
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>