From: Boris Z. (boris@conley.com)
Date: 07/15/99-08:01:19 AM Z
Message-ID: <01BECEA0.9B3DF250.boris@conley.com>
From: "Boris Z." <boris@conley.com>
Subject: RE: Proceedure ACCESS - new difinition
Date: Thu, 15 Jul 1999 09:01:19 -0400
Don't you want to add here a ACCESS4_SETATTR bit as well ?
If not, why not?
On Thursday, July 15, 1999 6:24 AM, Carl Beame [SMTP:beame@mail1.tinet.ie] wrote:
>
> As was mentioned at tghe IETF meeting here is a proposed revised
> definition for the ACCESS proceedure:
>
>
> 10.3. Procedure 2: ACCESS - Check Access Permission
>
> SYNOPSIS
>
> (cfh), permbits -> permmask, permbits
>
> ARGUMENT
>
> const ACCESS4_READ= 0x0001;
> const ACCESS4_LOOKUP= 0x0002;
> const ACCESS4_MODIFY= 0x0004;
> const ACCESS4_EXTEND= 0x0008;
> const ACCESS4_DELETE= 0x0010;
> const ACCESS4_EXECUTE= 0x0020;
>
> struct ACCESS4args {
> /* CURRENT_FH: object */
> uint32_t access;
> };
>
> RESULT
>
> struct ACCESS4resok {
> uint32_t supported_mask;
> uint32_t access;
> };
>
> union ACCESS4res switch (nfsstat4 status) {
> case NFS4_OK:
> ACCESS4resok resok;
> default:
> void;
> };
>
> DESCRIPTION
>
> ACCESS determines the access rights that a user, as identified by
> the credentials in the request, has with respect to a file system
> object. The client encodes the set of permissions that are to be
> checked in a bit mask. The server checks the permissions encoded
> in the bit mask. A status of NFS4_OK is returned along with a bit
> mask encoded with the permissions which the server can reliably
> return a valid access mask, also a bit mask encoded with the
> permissions that the client is allowed.
>
>
> The results of this procedure are necessarily advisory in nature.
> That is, a return status of NFS4_OK and the appropriate bit set in
> the bit mask does not imply that such access will be allowed to the
> file system object in the future, as access rights can be revoked
> by the server at any time.
>
> The following access permissions may be requested:
>
> ACCESS_READ: bit 1 Read data from file or read
> a directory.
> ACCESS_MODIFY: bit 2 Rewrite existing file data or modify
> existing directory entries.
> ACCESS_LOOKUP: bit 3 Look up a name in a
> directory (no meaning for
> non-directory objects).
> ACCESS_EXTEND: bit 4 Write new data or add
> directory entries.
> ACCESS_DELETE: bit 5 Delete an existing
> directory entry.
> ACCESS_EXECUTE: bit 6 Execute file (no meaning
> for a directory).
>
> The server must return an error if the any access permission cannot
> be determined.
>
> IMPLEMENTATION
>
> In general, it is not sufficient for the client to attempt to
> deduce access permissions by inspecting the uid, gid, and mode
> fields in the file attributes, since the server may perform uid or
> gid mapping or enforce additional access control restrictions. It
> is also possible that the NFS version 4 protocol server may not be
> in the same ID space as the NFS version 4 protocol client. In these
> cases (and perhaps others), the NFS version 4 protocol client can
> not reliably perform an access check with only current file
> attributes.
>
> In the NFS version 2 protocol, the only reliable way to determine
> whether an operation was allowed was to try it and see if it
> succeeded or failed. Using the ACCESS procedure in the NFS version
> 4 protocol, the client can ask the server to indicate whether or
> not one or more classes of operations are permitted. The ACCESS
> operation is provided to allow clients to check before doing a
> series of operations. This is useful in operating systems (such as
> UNIX) where permission checking is done only when a directory is
> opened. This procedure is also invoked by NFS client access
> procedure (called possibly through access(2)). The intent is to
> make the behavior of opening a remote file more consistent with the
> behavior of opening a local file.
>
> For NFS version 4, the use of the ACCESS procedure when opening a
> regular file is deprecated in favor of using OPEN.
>
> The information returned by the server in response to an ACCESS
> call is not permanent. It was correct at the exact time that the
> server performed the checks, but not necessarily afterwards. The
> server can revoke access permission at any time.
>
> The NFS version 4 protocol client should use the effective
> credentials of the user to build the authentication information in
> the ACCESS request used to determine access rights. It is the
> effective user and group credentials that are used in subsequent
> read and write operations.
>
> Many implementations do not directly support the ACCESS_DELETE
> permission. Operating systems like UNIX will ignore the
> ACCESS_DELETE bit if set on an access request on a non-directory
> object. In these systems, delete permission on a file is determined
> by the access permissions on the directory in which the file
> resides, instead of being determined by the permissions of the file
> itself. Thus, the mask returned of valid pmerissions will have
> the ACCESS_DELETE bit set to 0, indicating that the client does not
> support this permission check. The ACCESS_DELETE bit in the access mask
> returned will then be ignored by the client.
>
> ERRORS
>
> NFS4ERR_IO
>
> NFS4ERR_ACCES
>
> NFS4ERR_SERVERFAULT
>
> NFS4ERR_STALE
>
> NFS4ERR_BADHANDLE
>
> NFS4ERR_FHEXPIRED
>
> NFS4ERR_WRONGSEC
>
> - Carl
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:21 AM Z CST