From: Boris Z. (boris@conley.com)
Date: 07/01/99-09:40:10 AM Z
Message-ID: <01BEC3AE.1858EF40.boris@conley.com> From: "Boris Z." <boris@conley.com> Subject: RE: uid string Date: Thu, 1 Jul 1999 10:40:10 -0400 On Thursday, July 01, 1999 10:15 AM, Peter Staubach [SMTP:Peter.Staubach@Eng.Sun.COM] wrote: > > > > We are defining a way to represent arbitrary user ids via a > > "string" - but are not proposing any solution for for how users > > are to be represented in *any* security model such that inter-realm > > authentication is possible. > > > > So, as far as I can see, representing users as strings will > > chew up CPU as we convert "beepy" to "18" for AUTH_SYS repeatedly > > because even though Kerberos is defined to be basis for V4 (as > > an authentication flavor) most orgs are not going to implement > > Kerberos over night even if they by default upgrade to NFS V4 > > by installing new version of NetApp (:-) and NFS client of choice OS. > > > > New overhead exists. > > > > Does this really bother people? > > > > And, while we're at it, what is the client supposed to do with when it > receives "user@otherrealm", when it is required to do something like > return an integer through the system call interface? For example, I, > at Sun, ls(1) a file owned by "beepy@netapp.com". What does the > stat(2) return to the ls application? This question for a long time was bothering non-unix NFS client developers. The answer for this question should come from the protocol - did not we include it in ACCESS()? > > We have a hammer, are we trying to make the entire world a nail? > > ps >
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:17 AM Z CST