When mounted with the cifsacl mount option, we were
treating any deny ACEs found like allow ACEs and it turns out for
SFU and SUA Windows set these type of access control entries often.
The order of ACEs is important too. The canonical order that most
ACL tools and Windows explorer consruct ACLs with is to begin with
DENY entries then follow with ALLOW, otherwise an allow entry
could be encountered first, making the subsequent deny entry like "dead
code which would be superflous since Windows stops when a match is
made for the operation you are trying to perform for your user
We start with no permissions in the mode and build up as we find
permissions (ie allow ACEs). This fixes deny ACEs so they affect
the mask used to set the subsequent allow ACEs.
Acked-by: Shirish Pargaonkar <shirishp@us.ibm.com>
CC: Alexander Bokovoy <ab@samba.org>
Signed-off-by: Steve French <sfrench@us.ibm.com>
We were requesting GENERIC_READ but that fails when we do not have
read permission on the file (even if we could read the ACL).
Also move the dump access control entry code into debug ifdef.
Signed-off-by: Steve French <sfrench@us.ibm.com>
Part 9 of ACL patch series. getting mode from ACL now works in
some cases (and requires CIFS_EXPERIMENTAL config option).
Signed-off-by: Shirish Pargaonkar <shirishp@us.ibm.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Now GetACL in getinodeinfo path when cifsacl mount option used, and
ACL is parsed for SIDs. Missing only one piece now to be able
to retrieve the mode
Signed-off-by: Steve French <sfrench@us.ibm.com>
