From: Noveck, Dave (dave.noveck@netapp.com)
Date: 07/05/99-08:31:12 AM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA03303694@tahoe.corp.netapp.com> From: "Noveck, Dave" <dave.noveck@netapp.com> Subject: RE: uid string Date: Mon, 5 Jul 1999 06:31:12 -0700 > I think Ram alluded to two separate problems that we have to solve > and I think they are getting unnecessarily intertwined: > > 1) What is the principal name use the the security > authentication > mechanism and how do clients transform their native > credential > into the principal and how does the server translate it back. > > 2) When looking at ther attributes of a file, how is > the server's > native concept of an owner translated over the wire. > > In the case of #1, we already have existence proofs with AUTH_DES and > Kerberos how this is done. And for non-Unix hosts AUTH_SYS. In > general there is not one format for the principal that all security > systems can use, so all clients and all servers will need to > be prepared > to translate as needed. > > For case #2, traditionally permissions to manipulate a file have > be controlled on the server based on the credentials passed in. A > well behaved client must use the ACCESS procedure before it can > assert any priviledge. Using the value in the attributes is not > sufficient. Thus the attribute of "owner" is simply a display > mechanism which a few not so well written applications might > try to use as authentication. > > It would seem perfectly reasonable that a Unix server encode > its uid/gid > in an attribute that a Unix client can use to display in "ls". If > a non-Unix server doesn't present this uid then it is up to the Unix > client to figure out what to do (eg. display a string owner > if available). > But this shouldn't affect the security model, only the display model. If I do a chown, generally I do it for some other purpose than to change what someone will see on ls. That at least is the common expectation. Whether a chown will have this effect will I guess depend on whether ACL's support the concept of owner. POSIX ACL's, at least in the Draft 15 (latest) incarantion, do have entries which designate the permissions to be granted to the owning user (or the owning group), whatever that happens to be. I was assuming that in the absence of user-specified ACL, UNIX client would formulate one using such entry types out of the magic nine bits that we've come to know and feel ambivalent about. I know that nfs-v4 is supposed to be less tied to unix here but it is going to have to support unix at least as well as v3 or it isn't going to be used. I can't see how a whole range of things are going to work if owner and owning-group are drained of their pervious significance and become something to display.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:19 AM Z CST