HP StoreAll Storage - Manual (Page 91)

but will not be inherited or propagated. The CIFS server also does not map POSIX ACLs to be
compatible with Windows ACLs on a file.
These permission mechanisms have some ramifications for setting up shares, and for cross-protocol
access to files on an X9000 system. The details of these ramifications follow.
Permissions, UIDs/GIDs, and ACLs
The X9000 Software CIFS server does not attempt to maintain two permission/access schemes on
the same file. The CIFS server is concerned with maintaining ACLs, so performs ACL inheritance
and honors ACLS. The UID/GIDs and permission bits for files on a directory tree are peripheral
to this activity, and are used only as much as necessary to obtain access to files on behalf of a
Windows client. The various cases the CIFS server can encounter while accessing files and
directories, and what it does with UID/GID and permission bits in that access, are considered in
the following sections.
Pre-existing directories and files
A pre-existing Linux directory will not have ACLs associated with it. In this case, the CIFS server
will use the permission bits and the mapped UID/GID of the CIFS user to determine whether it has
access to the directory contents. If the directory is written by the CIFS server, the inherited ACLS
from the directory tree above that directory (if there are any) will be written into the directory so
future CIFS access will have the ACLs to guide it.
Pre-existing files are treated like pre-existing directories. The CIFS server uses the UID/GID of the
CIFS user and the permission bits to determine the access to the file. If the file is written to, the
ACLs inherited from the containing directory for the file are applied to the file using the standard
Windows ACL inheritance rules.
Working with pre-existing files and directories
Pre-existing file treatment has ramifications for cross-protocol environments. If, for example, files
are deposited into a directory tree using NFS and then accessed using CIFS clients, the directory
tree will not have ACLs associated with it, and access to the files will be moderated by the NFS
UID/GID and permissions bits. If those files are then modified by a CIFS client, they will take on
the UID/GID of the CIFS client (the new owner) and the NFS clients may lose access to those files.
New directories and files
New directories created in a tree by the Windows client inherit the ACLs of the parent directory.
They ACLs are created with the UID/GID of the Windows user (the UID/GID that the SID for the
Windows user is mapped to) and they have a Linux permission bit mask of 700. This translates to
Linux applications (which do not understand the Windows ACL) having owner and group (users
with the same group ID) with read, write, execute permissions, and everyone else having just read
and execute permissions.
New files are handled the same way as directories. The files inherit the ACLs of the parent directory
according to the Windows rules for ACL inheritance, and they are created with a UID/GID of the
Windows user as mapped from the SID. They are assigned a permissions mask of 700.
Working with new files and directories
The inheritance rules of Windows assume that all directories are created on a Windows machine,
where they inherit ACLs from their parent; the top level of a directory tree (the root of the file system)
is assigned ACLs by the file system formatting process from the defaults for the system.
This process is not in place on file serving nodes. Instead, when you create a share on a node,
the share does not have any inherited ACLs from the root of the file system in which it is created.
This leads to strange behavior when a Windows client attempts to use permissions to control access
to a file in such a directory. The usual CREATOR/OWNER and EVERYBODY ACLs (which are a
part of the typical Windows ACLS inheritance ACL set) do not exist on the containing directory for
Permissions in a cross-protocol CIFS environment 91