Open System Services Programmer's Guide

) or chmod( ) functions and are ignorant of ACLs are more likely to produce expected results.
The st_acl field indicates the presence of optional ACL entries in the ACL for the file. The
st_basemode field provides the owning user permissions, owning group permissions, and other
permissions for the file.
ACL Interaction with chmod()
Using the chmod( ) function to set the group permission bits affects the class: entry for the
file, which in turn affects the permissions granted by additional user:uid: and group:gid:
entries. In particular, using chmod( ) to set file permission bits to all zeros removes all access
to the file, regardless of permissions granted by any additional user:uid: or group:gid:
entries. If the chmod( ) function is used on an object that does not have optional ACL entries,
both the class: ACL entry and the owning group (group::) ACL entry permission bits are
changed to the new group permissions value.
ACL Interaction with chown()
If you use the chown( ) function to change the owner or owning group of a file to a user ID or
group ID that has an existing user:uid: or group:gid: entry in the ACL for the file, those
existing entries are not removed from the ACL. However, those existing entries no longer have any
effect, because the user:: or group:: entries take precedence.
OSS Network File System (NFS) and ACLs
For J06.09 and later J-series RVUs and H06.20 and later H-series RVUs, access by the OSS Network
File System (NFS) to OSS objects that have OSS ACLs that contain optional ACL entries can be
allowed, depending upon the NFSPERMMAP attribute value for the OSS fileset that contains the
object.
The system software on NFS Version 2 (NFS V2) client systems makes its own access decisions
based on its interpretation of the permissions bits of the object. Because NFS Version 2 does not
provide support for ACLs, the ACL entries must be mapped to the nine basic permissions bits used
for objects in NFS. An object that is protected by an ACL cannot reflect the correct access for all
users in these nine permission bits. It might be that access that would be granted by the mapped
permission bits is actually denied explicitly by the ACL. It might also be that access that seems to
be denied by the mapped permission bits is, in fact, granted explicitly by the ACL. The
NFSPERMMAP attribute value selects the algorithm used to map the OSS ACL permissions for the
object to the standard permissions (rwxrwxrwx) expected for the object by NFS V2 clients. For
information about the NFSPERMMAP attribute, see the Open System Services Management and
Operations Guide.
NOTE: If an OSS fileset has objects protected by OSS ACLs, that fileset must be mounted from
the NFS client systems using mount options that disable write buffering. Disabling write buffering
on the NFS client system causes NFS write requests from the NFS client systems to contain the
actual effective user id of the writing client process, which enables the NonStop system to properly
enforce the OSS ACL permissions. For example, the mapped NFS permissions can indicate to an
NFS client system that a user has write permission to a file when in fact that specific user is denied
in the OSS ACL on the NonStop system. In this case, an NFS write request that is denied by an
OSS ACL on the NonStop system is likely to be reported to the NFS client application as an EIO
or EPERM error.
Because of the behavior of some NFS V2 clients, if you do not disable write buffering, the server
might not receive the correct user ID information from the NFS client, which can result in write
requests being denied or data being written to a file by a client that should have been denied
write access. See the description of the OSS fileset NFSPERMMAP attribute in the Open System
Services NFS Management and Operations Guide.
Using OSS Access Control Lists (ACLs) 267