HP StoreAll Storage - Manual (Page 71)

Differences in locking behavior
When CIFS clients access a share from different servers, as in the X9000 Software environment,
the behavior of byte-range locks differs from the standard Windows behavior, where clients access
a share from the same server. You should be aware of the following:
•
Zero-length byte-range locks acquired on one file serving node are not observed on other file
serving nodes.
•
Byte-range locks acquired on one file serving node are not enforced as mandatory on other
file serving nodes.
•
If a shared byte-range lock is acquired on a file opened with write-only access on one file
serving node, that byte-range lock will not be observed on other file serving nodes. ("Write-only
access" means the file was opened with GENERIC_WRITE but not GENERIC_READ access.)
•
If an exclusive byte-range lock is acquired on a file opened with read-only access on one file
serving node, that byte-range lock will not be observed on other file serving nodes. ("Read-only
access" means the file was opened with GENERIC_READ but not GENERIC_WRITE access.)
Permissions in a cross-protocol CIFS environment
The manner in which the CIFS server handles permissions affects the use of files by both Windows
and Linux clients. Following are some considerations.
How the CIFS server handles UIDs and GIDs
The CIFS server provides a true Windows experience for Windows users. Consequently, it must
be closely aligned with Windows in the way it handles permissions and ownership on files.
Windows uses ACLs to control permissions on files. The CIFS server puts a bit-for-bit copy of the
ACLs on the Linux server (in the files on the X9000 file system), and validates file access through
these permissions.
ACLs are tied to Security Identifiers (SIDs) that uniquely identify users in the Windows environment,
and which are also stored on the file in the Linux server as a part of the ACLs. SIDs are obtained
from the authenticating authority for the Windows client (in X9000 Software, an Active Directory
server). However, Linux does not understand Windows-style SIDs; instead, it has its own permissions
control scheme based on UID/GID and permissions bits (mode bits, sticky bits). Since this is the
native permissions scheme for Linux, the CIFS server must make use of it to access files on behalf
of a Windows client; it does this by mapping the SID to a UID/GID and impersonating that UID/GID
when accessing files on the Linux file system.
From a Windows standpoint, all of the security for the X9000 Software-resident files is self-consistent;
Windows clients understand ACLs and SIDs, and understand how they work together to control
access to and security for Windows clients. The CIFS server maintains the ACLs as requested by
the Windows clients, and emulates the inheritance of ACLs identically to the way Windows servers
maintain inheritance. This creates a true Windows experience around accessing files from a
Windows client.
This mechanism works well for pure Linux environments, but (like the CIFS server) Linux applications
do not understand any permissions mechanisms other than their own. Note that a Linux application
can also use POSIX ACLs to control access to a file; POSIX ACLs are honored by the CIFS server,
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
Permissions in a cross-protocol CIFS environment 71