From: Craig_Everhart@transarc.com
Date: 09/22/98-10:41:24 AM Z
Message-Id: <sq1wIYeSMVcC1KEZc0@transarc.com> Date: Tue, 22 Sep 1998 11:41:24 -0400 (EDT) From: Craig_Everhart@transarc.com Subject: Re: Comments on NFSv4 requirements document Excerpts from transarc.external.nfs4-wg: 21-Sep-98 Comments on NFSv4 requireme.. Brent Callaghan@Eng.Sun. (12178*) > > 5.2. Extended Attributes > > > > NFS does not provide for file or directory attributes beyond those > > that are found in the traditional Unix environment; for example the > > user identifier of the owner of the file, a permission or access > > bitmap, time stamps for modification time of the file or directory > > and file size to name a few. While the current set of attributes has > > usually been sufficient, the file system's ability to manage > > additional information associated with a file or directory can be > > useful. > > > > Editors Note: Need to add examples of the use or potential > > extended attributes. > - DOS archive bit > - DOS "hidden" bit > - An opaque consistency attribute > - An indication of file compression or encryption > - An immutable time (indicates when file may be modified) - A MIME type to indicate file content How about some indication that some or all of the file's data is under management, such as in an HSM system? In a DMAPI (``XDSM'' is the X/Open name) world, for instance, it would be good for a client to know that some operations on a file would be mediated by a data-management process external to the file system itself. (The typical Unix implementation requires a user-space process to respond to an invocation before a file's data access completes.) > At first glance ACLs appear to be much the same across POSIX, DCE/DFS > and Windows NT: they all consist of a sequence of access control entries > that can name a user, group or "special" entry and contain access bits. > However, the details in the semantics are all quite different. It may > be possible to map all three into a consistent ACL representation that's > suitable for viewing purposes, but a common ACL manipulation protocol > might be something that continues to elude NFS. I'd be glad of any opinions to the contrary. (DCE) DFS ACLs should be seen as a straightforward extension of POSIX--they were heavily constrained by the POSIX documents. They retain most or all of the POSIX specification of how access should be evaluated: either find an exact match for all the specific-user entries on the ACL, or use the union of all group matches, or use a no-match-found entry. The (DCE) DFS extensions are that there are additional entry types for describing inter-realm accesses. Thus, in the category of ACL entries that name specific users, there's an entry type that indicates the file's owner, an entry type that names a specific user in the default (usually local) security realm, and an entry type that names a specific user in some other security realm. For group entry types, there's an entry type that names the file's owning-group, one for a group in the default security realm, one for a group in some other security realm, and one for anyone authenticated in a given security realm (whether default or not). Presumably, NFS (v4) would have to specify some general ACL form. At least the following attributes of ACLs would have to be accommodated: - how identities are indicated, i.e. in what security registry - what actions are permitted by the ACL entry (e.g. rwx (Unix), rwxcid (POSIX and DCE DFS), rwxd (? NTFS), rlidwka (AFS)) - how ACLs, i.e. sets of ACL entries, are evaluated: -- POSIX/DCE (individual-specific entries override group membership) -- AFS (both positive-rights and negative-rights on ACL) POSIX (and thus DCE) also includes mask_obj, which is a mechanism for allowing some interesting kinds of interoperability between ACL-aware applications and applications that know only mode bits. (To be fair, there's actually no POSIX specification for ACLs; I believe that work was abandoned, and that successive POSIX drafts either included or excluded the mask_obj functionality.) I'll spare you that piece of semantics for now, though. > > Editors Note: Should identify what other distributed file > > systems do for naming and if these approaches can help > > solve the issues above or are themselves limited. > AFS volumes and domains are located in "cells" that are identified > by DNS domain strings. However, I don't know what happens when > a user in one cell creates a file in another cell. Presumably the foreign user gets a local cell ID. This is basically the same issue as how ACL entries name users and groups. The original AFS model is that cells are autonomous, so that you obtain credentials from a given cell, and those credentials are used for access to files in that cell. There's a system-defined userid that represents unauthenticated users, so if you don't have credentials in a cell but you create a file in that cell (due to open permissions), the owner for the cell is the unauthenticated user. There are system-defined groups, usable on ACLs, that describe the set of all locally-authenticated users as well as the set of all users, authenticated or not. AFS ACLs permit mention of local-cell users and local-cell groups on ACLs, not foreign users or groups. ACLs are present only on directories, so of the ACL rights (rlidwka), some apply to the directory itself (l (lookup), i (insert), d (delete), a (administer)), some apply to contained files (w (write)), and some apply to both (r (read), k (lock)). AFS also recognizes cross-cell authentications, whereby the underlying Kerberos for cell A might recognize a user in cell B if there's an appropriate trust relationship. This would mean, I believe, that user@cellB has a Kerberos identity in cell A, so that the ACL entry is still in some sense local to cell A, even if the print-name for the Kerberos identity is user@cellB (user@cellB@cellA). The owning userid is still taken from the number space associated with cell A, and it corresponds to the number allocated when the user@cellB account was created in cell A. (At least I think that's how it works.) DFS uses the DCE model, where cells are not independent, and where a given session has only one identity at a time. Thus, you're still user@cellA even if you do file I/O to file servers in cell B. If there's a trust relationship between cells A and B, and user@cellA creates a file that's stored in cell B, then the file gets an explicit ACL that specifies the default realm to be cell A, and the userid for the owner is the numeric userid that user@cellA has in cellA. The same thing happens for group storage. Thus, if there's an ACL for a file, the owner and owning-group for a file need to be interpreted relative to the default realm listed in the ACL. If there's no trust relationship between cells A and B, or if the creator isn't authenticated, the owner and owning group will both be set to reserved values that indicate that the access was unauthenticated. DCE (and thus DFS) compactly specifies a cell name not by string name, but by UUID, which is a 16-byte identifier that should be globally unique upon creation. You locate a cell by string name, but you quickly learn the UUID that the cell's security registry (including users/principals and groups) associates with itself, and this is the UUID that gets recorded in ACLs to specify foreign users/groups and as the default-realm UUID for an ACL. Now, users (principals) and groups are also identified as UUIDs (user UUID within cell/realm UUID), but these UUIDs are specially constructed so that the first 32 bits is actually usable as an owner UID or an owning-group GID. So the boiled-down representation of a user or a group in a DCE or DFS ACL is (32bit UID or GID)@(128bit cell UUID). > Some indication to a proxy that a file is accessible to anyone would > benefit caching of public data. The v2 and v3 file permission bits > can be inaccurate if the file is protected by an ACL on the server. > The ACCESS call is defined only for a single user - not for "anyone". Maybe there should be some defined credential that would indicate ``anyone'' so that a proxy, or for that matter a (cacheing) client, to determine the correct permission bits. > A request that is forwarded through a proxy server must contain > the name or address of the NFS server to which the request is > ultimately directed. The protocol must allow the proxy to read this header even if the rest of the NFS request is encrypted. I guess I don't understand why this requirement is suggested. Craig
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:16 AM Z CST