5.6 HP StorageWorks X9000 File Serving Software User Guide (TA768-96035, June 2011)

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 the management console creates
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 the share, and are not inherited downward into the share
directory tree. For true Windows-like behavior, the creator of a share must access the root of the
share and set the desired ACLs on it manually (using Windows Explorer or a command line tool
such as ICACLS). This process is somewhat unnatural for Linux administrators, but should be fairly
normal for Windows administrators. Generally, the administrator will need to create a
CREATOR/OWNER ACL that is inheritable on the share directory, and then create an inheritable
ACL that controls default access to the files in the directory tree.
Permissions in a cross-protocol CIFS environment 65