6.5 HP StoreAll OS User Guide

but will not be inherited or propagated. The SMB 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 a StoreAll system. The details of these ramifications follow.
Permissions, UIDs/GIDs, and ACLs
The SMB server does not attempt to maintain two permission/access schemes on the same file.
The SMB 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 SMB 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 SMB server
will use the permission bits and the mapped UID/GID of the SMB user to determine whether it has
access to the directory contents. If the directory is written by the SMB server, the inherited ACLS
from the directory tree above that directory (if there are any) will be written into the directory so
future SMB access will have the ACLs to guide it.
Pre-existing files are treated like pre-existing directories. The SMB server uses the UID/GID of the
SMB 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 SMB 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 an SMB client, they will take on
the UID/GID of the SMB 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
the share, and are not inherited downward into the share directory tree. For true Windows-like
Permissions in a cross-protocol SMB environment 115