Univention Bugzilla – Bug 42531
Check reason of failure of user access to files in samba share
Last modified: 2019-01-03 07:23:17 CET
It would be useful to have a tool that can be run to discover the reason, why a user cannot (or can) access a file in a samba share. Use cases: * an issue accessing a file in a subdirectory, e.g. due to lack of access permissions on a parent directory, e.g. due to nesting of shares * an issue with GPO ACLs in sysvol share Motivation: We have had support cases where users reported problems for some users or user groups to access some files in some (Samba) file share. In the cases I recall this was due to a lack of access permission to a parent directory for that user or group. In these cases this was caused by the customer who had configured a setup of nested (Samba) file shares, i.e. the customer created second share with a backing directory that was a subdirectory of another share (or the other way around). In these cases a tool would have been useful that would answer the question "why can this user not access that particular file". A tool like that should check these layers: 1. the frontend server access on SMB level (smbclient) to that file 2. the backend access on Linux filesystem level to that file 3. the NTACLs of the file and the containing directory 4. the fACLs of the file and the containing directories (possibly also setGID) 5. check if Posix IDs in fACL match SIDs in NTACL (Note: Samba always updates the fACLs in case the NTACLs are modified and it updates the NTACLs in case the fACLs have been changed behind its back) 6. check if the Samba share has some nasty options set (force user etc.) 7. check if the share is nested below another share (which may have options set) I would recommend implementing the basic check methods as a python module wich can later be reused in a separate general share monitoring tool which may e.g. be used via UMC System Diagnostic or via Nagios. To make the difference clear: That tool would probably not be an audit (or IDS) tool which checks everything of the above for each possible user, but that tool would only check 5 and 7 as a first step and thus would not be able to answer the support question stated above.
FYI: For the GPO case samba-tool sysvolcheck can check the consistency of NTACLs against the nTSecurityDesciptors in Samba/AD (when Bug 33163 gets fixed).
Cut&paste error in comment above: I wanted to refer to Bug 39633
Created attachment 8817 [details] Check file access per SMB and direct FS acces and try to find the problem cause. The attached script tries to find and diagnose problems while accessing files over SMB, as described in comment c0. NT ACLs are checked as described in https://msdn.microsoft.com/en-us/library/aa446683(v=vs.85).aspx . Posix ACLs require the package `python-pylibacl` and are evaluated as in `man acl` - ACCESS CHECK ALGORITHM.
Created attachment 8838 [details] check_file_access.py.diff I just tried it and received this trivial traceback. A few more suggestions in the attached diff. root@master10:~# ./check_file_access.py --is-smb-path --no-filesystem --no-share-configuration --verbose --user user1 --privileged-user Administrator "//localhost/user1/Sicherung E" Password for user1: Password for Administrator: Traceback (most recent call last): File "./check_file_access.py", line 865, in <module> main() File "./check_file_access.py", line 860, in main path = resolve_smb_path_to_local_path(path, user=args.user) TypeError: resolve_smb_path_to_local_path() got an unexpected keyword argument 'user' Also, can't we detect --is-smb-path via path.startswith('//')?
Created attachment 8839 [details] Check file access per SMB and direct FS acces and try to find the problem cause. Applied some of the changes and fixed other issues: - (Slightly) better error messages - SMB path detection via path.startswith("//") + new flag `--force-local-path` to disable the detection - handling of non-existing files and directories - handling of the SMB root directory while access check
Created attachment 8840 [details] Check file access per SMB and direct FS acces and try to find the problem cause. Fixing an invalid `os.listdir()` call.
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.