From: Brent Callaghan (Brent.Callaghan@eng.sun.com)
Date: 07/01/99-04:04:51 PM Z
Date: Thu, 1 Jul 1999 14:04:51 -0700 (PDT) From: Brent Callaghan <Brent.Callaghan@eng.sun.com> Message-Id: <199907012104.OAA01853@terra.eng.sun.com> Subject: Re: uid string My expectation is that NFS v4 will make it practical to access files over the Internet. That expectation is also expressed in the WG charter and in the Design Specifications document. A flat numeric UID space cannot work on the Internet unless there is some structuring applied to the number, as in IPv4 and IPv6 addresses. Nobody has proposed a structured numeric UID for v4, though we should certainly consider one if proposed. I'm not religious about strings vs numbers. The requirement is that user identification be scalable and interoperable. If it's to be strings, then we should certainly consider existing string-based identifiers such as the Kerberos principal@realm - but not tie the protocol to exclusive use of Kerberos. If NFSv4 needs to live in a world with multiple naming schemes for individuals, then we could consider some kind of tag that identifies the scheme - much as each URL begins with a URL scheme identifier like "http" or "ftp". For instance, the first character of the string might be used to identify the format for the rest of the string: Kbrent@foobar - Kerberos Dbrent@foobar - DCE U456 - UNIX uid S12.345.678.9 - NT SID While this can be extended to encompass lots of different naming schemes, it smacks of "receiver-make-it-right" from the old XDR vs NCS wars. It puts a burden on each client and server to implement a lot of different schemes and NFS isn't lean `n mean anymore. My preference is to have a canonical representation on the wire. Something that can be made to work with all of those existing schemes. For instance, when we log into a computer or network, we normally use a string that we know as our "login" name. Behind the scenes that gets mapped to something else, e.g. Kerberos id. I'd assume that those organizations that have multiple user databases have the forethought to set up a common login string across all of those databases, e.g. if I log into my NT box I use the same login name and password as I'd use on my UNIX box. So, let's start by using the user's login name as the primary string. Obviously, that login name won't be unique right across the Internet. That leaves the "@domain" part to be figured out. Figuring out a unique string for the domain part isn't particularly difficult - we could just use the DNS domain as is used for mail and IP addresses. The real problem here is figuring out a way to use that domain string to bind to a name service that will map the login name into a local UNIX UID or NT SID.... Brent
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:18 AM Z CST