Users coming through various protocols see the same set of files. The Unified Storage Device (USD) figures out whether users have the rights to perform operations on those files. Currently this is done by deciding that you are either a Windows user or a UNIX user.
The authentication is made through a combination of protocol and authentication method. The following table lists the combinations:
|
Request |
User type |
|
NFS |
UNIX |
|
HTTP with basic authentication |
UNIX |
|
FTP with basic authentication |
UNIX |
|
CIFS |
Windows |
|
HTTP with NTLM authentication |
Windows |
|
FTP with NTLM authentication |
Windows |
|
WebDAV |
Windows |
When a request comes through UNIX, it contains file system IDs (FSIDs), a user ID (UID), group IDs (GID), inode numbers, and so on. A Windows request comes with a path name, user SID, Group SID list, file offset, and so on. There is neither a one-to-one mapping between them, nor between the permission and Access Control List (ACL) (ACLs are more expressive than permissions). There is a one-to-one mapping of a user's identity in the Windows space and its identity in the UNIX space. For this reason, the storage system does user name mapping. If your account name in Windows is the same as your UNIX account, by default, your UNIX account is used if you come in through Windows to use a UNIX file, or vice versa. The special name mapping file /etc/usermap.cfg allows other mappings.
Following are the four possible cases:
A UNIX user requests a file with UNIX file permissions on it.
The USD compares the UID and GID list and requested operation against the file owner, group, and permissions, and grants or denies access.
A Windows user requests a file with an ACL.
The USD compares the SID and requested operation against the Access Control Entries (ACEs) in the ACL until access is granted or denied.
A UNIX user requests a file with an ACL.
The USD uses the name service mechanism (/etc/passwd, Network Information Service, or Lightweight Directory Access Protocol, as specified in /etc/nsswitch.conf) to retrieve the account name of the user who makes a request.
The USD uses the name mapping feature to map the UNIX name to a Windows account name.
The USD queries the Domain Controller (DC) or applicable Windows authority to get the account SID and group SID list.
The USD caches the result of the user's query for a few minutes. This is because DC lookup is slow and has to be done on every NFS request, and not just at session setup time as in Windows.
Authorization continues as in the second case.
A Windows user requests a file with permissions on it.
The USD queries the DC for an account name corresponding to the SID in the request. This is done only once per session; therefore, the result is not cached.
The USD uses the name mapping feature to get a UNIX account name.
The USD queries the name service in use to get the UID and GID for that account.
Authorization continues as in the first case.
The USD allows the following kinds of qtrees to set file permissions:
"unix" qtrees
The only kind of permissions that can be set in a unix qtree are traditional UNIX permissions.
Files can have ACLs on them because you can change qtree security styles. These are discarded the next time permissions are set on the files.
"ntfs" qtrees
The only kind of permissions that can be set in an ntfs qtree are traditional Windows ACLs.
Files can have permissions on them, because you can change qtree security styles. Setting permissions on these files writes an ACL that overrides the permissions.
"mixed" qtrees
A file's permissions in a mixed qtree are determined by the last system that sets them. Setting unix permissions removes any ACL already present on the file, and setting an ACL overrides any UNIX permissions already on the file.
People mostly touch the same files from the same systems. Even when they touch them from both directions, as happens in Engineering environments, people typically set permissions using one system or the other.
Related Topics