From: Brent Callaghan (Brent.Callaghan@eng.sun.com)
Date: 06/30/99-03:46:59 PM Z
Date: Wed, 30 Jun 1999 13:46:59 -0700 (PDT) From: Brent Callaghan <Brent.Callaghan@eng.sun.com> Message-Id: <199906302046.NAA01098@terra.eng.sun.com> Subject: Re: uid string Rick Macklem writes: > ... Adding "@dns_domain" doesn't seem to add much either, since > the client should already know the dns_domain of the server (or at least the > IP address) and user names aren't normally administered on a dns_domain > basis anyhow. Ah, but the server isn't necessarily in the same domain as the one in which the user is administered. > One thought would be to tie the "uid string" to the authentication system > being used. For example, It would be nice to use a pre-existing scheme for identifying users, such as that of Kerberos. However, I think it would be a mistake to tie the string format to the client's authentication. For instance, how do you identify users who created files on the server through a different authentication scheme from that used by the client ? > On implementation of a uid string in a Unix-like system: > - Getting from a uid number to the login name is going to be a Royal Pain in.. > for a kernel based implementation. The implementor will either have to put > getpwnam(), getpwuid() and all the baggage that it needs, such as a NIS > client in the kernel, or the kernel threads will have to "porpoise" out of > the kernel to make the calls. Right. It will require more work for UNIX clients and servers that currently have it easy with NFS v2 & v3 through the direct use of uid/gid when using AUTH_SYS. However, if you're going to use any kind of secure authentication, then you're stuck with doing some kind of mapping anyway. You don't need to put a NIS client in the kernel. It's easy to to upcalls to a daemon that'll do all the name service jiggerypokery. As long as you cache the mappings, the client or server performance needn't suffer. Brent
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:16 AM Z CST