Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

A method for translation and foreign identity mapping of NFS V4 owner strings and principals, and a method of storage and retrieval of foreign identity mapping schema using IBM Enterprise Identity Mapping (EIM)

IP.com Disclosure Number: IPCOM000029983D
Original Publication Date: 2004-Jul-21
Included in the Prior Art Database: 2004-Jul-21
Document File: 6 page(s) / 88K

Publishing Venue

IBM

Abstract

The Network Filesystem Version 4 protocol (NFS V4) requires that the owner and owner_group attributes of a file be represented as a "user@dns_domain" string format. The following will disclose an algorithm to perform the necessary identity mappings, as well as a reliable method to store and retrieve identity mapping data, needed to support NFS V4.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 35% of the total text.

Page 1 of 6

A method for translation and foreign identity mapping of NFS V 4 owner strings and principals, and a method of storage and retrieval of foreign identity mapping schema using IBM Enterprise Identity Mapping (EIM)

The following will disclose an algorithm to perform the necessary identity mappings, as well as a reliable method to store and retrieve identity mapping data, needed to support the NFS V4.

When a NFS V4 client or server receives a "user@domain" string, it needs to be able to map that string into something that it can handle, a user ID (UID) or a group ID (GID). Likewise, when a NFS V4 client or server needs to send its information out, it needs to map the UID or GID into a " user@domain" string. If these mapping requests are not already cached in the kernel, then a request is sent to a name registry daemon.

There are four sets of mappings rules needed in the registry daemon: incoming and outgoing server strings, incoming client strings, and authentication space to domain mapping rules. All client and server mapping rules can be generalized to a source_user@source_domain to target_user@target_domain mapping. Mapping rules for outgoing client strings are not needed. A special NFS_NOBODY variable refers to a string that signifies an anonymous user or group, and is set by the system administrator. This allows clients and servers to have their own local representation of the NFS "nobody" user or group.

Conceptually, the identity mapping rules are as follows:

Conceptual Client and Server String Mapping Rules

format:

SOURCE: src_name@src_dns_domain

target_domainA mapped_nameA

target_domainB mapped_nameB

.

.

example:

SOURCE: johnsdoe@us.ibm.com

austin.ibm.com jsd

pok.ibm.com jsd

rochestor.ibm.com jdoe

SOURCE: robert@us.ibm.com

austin.ibm.com rob

armonk.ibm.com robert

1

Page 2 of 6

Conceptual Authentication Space to Domain Mapping Rules

format:

AUTH_SPACE: authentication_space mapped_domain

example:

AUTH_SPACE: aixkerb.austin.ibm.com austin.ibm.com

AUTH_SPACE: aixkerb.us.ibm.com us.ibm.com

The actual algorithm for the identity mappings are as follows:

Logical Description of Server ID /String Mapping Semantics

Generating a Domain from a Realm (Kerberos Only)

if (domain mapping exists for given realm)

domain = mapped dns_domain value else

domain = realm value

Generating an NFS V4 Owner String from UID/GID Values

obtain name (user or group) from the system's user registry (libc) if (no entry in user registry for uid or gid) return numeric from of owner string (eg "1234") } else if (name == $NFS_NOBODY) /* admin assigned or a default */ return owner string of "nobody" } else if (outgoing mappings exist for name) { get target client's domain (cl_domain) by mapping client realm

if (map entry domain == cl_domain) {

return map entry string (map_name@cl_domain)

} else {

return name@server's_domain

}

} else {

return name@server's_domain }

Mapping an Incoming String into UID /GID Values

2

Page 3 of 6

if owner_string is the numeric string form...