ACL Permissions set incorrect by Windows AD
Description
Problem/Justification
Impact
Activity
Bonnie Follweiler October 14, 2021 at 7:16 PM
Thank you for the report, @Alexander .
What specific version of Truenas were you seeing this issue in? Also, can you please attach a debug file to this ticket? To generate a debug file on TrueNAS CORE, log in to the TrueNAS web interface, go to System > Advanced, then click Save Debug and wait for the file to download to your local system. In TrueNAS SCALE, this option is in System Settings > Advanced.
Andrew Walker September 20, 2021 at 1:08 PMEdited
In AD (and windows in general) there is a unified RID pool for all objects, but in Unix we separate out GIDs from UIDs. There needs to be some mechanism to map these (SIDs to UIDs or GIDs, and vice-versa).
In Windows, a group may own an object, but this is not the case in Unix. There needs to be some ability to handle this when sync-ing security info between Windows server and Unix server.
In AD, an object may have historical SIDs from former domain (SID history). The historical SIDs need to be mapped to a user's unix token as additional groups (even though they were once users).
When joined to AD, some idmap backends (IDMAP_RID and IDMAP_AUTORID) support mapping SIDs from AD to both a user and a group (ID_TYPE_BOTH).
root@truenas[~]# id smbuser@BILLY.GOAT
uid=100001106(BILLY\smbuser) gid=100000514(BILLY\domain users) groups=100000514(BILLY\domain users),100001106(BILLY\smbuser),90000002(BUILTIN\users)
root@truenas[~]# getent passwd "domain users"@BILLY.GOAT
BILLY\domain users:*:100000514:100000514::/home/BILLY/domain users:/bin/shSee nss_winbind and relevant idmap manpages for more details.
If we receive request to set security info from SMB client and payload for new NT Security Descriptor contains a SID that is converted through an idmap backend supporting ID_TYPE_BOTH, then following logic applies:
switch (unixid.type) {
/*
* The SID resolves to both a GID and a UID. In this situation,
* we prefer to convert to a group entry except in a few edge cases.
* 1) If the SID is also the Group in the Security Descriptor
* _and_ it is not inheritable. In this case we convert to the special
* "group@" entry. This undoes the NFSv4 "simple" conversion performed on ACL read.
* 2) If the SID is also the User in the Security Descriptor _and_ it is not
* inheritable, then add a secondary non-inheriting "owner@" entry.
*/
case ID_TYPE_BOTH:
tag = ACL_GROUP;
id = unixid.id;
if ((sbuf.st_ex_uid == id) &&
!nt_ace_is_inherit(ace_nt->flags)) {
tag2 = ACL_USER_OBJ;
id2 = ACL_UNDEFINED_ID;
add_ace2 = true;
}
if ((sbuf.st_ex_gid == id) &&
!nt_ace_is_inherit(ace_nt->flags)) {
tag = ACL_GROUP_OBJ;
id = ACL_UNDEFINED_ID;
}
break;I.e. we default to setting group unless id matches either file user or group and no inheritance bits are set in the request.
For inheritable ACEs, S-1-3-0 (creator owner) should be used to specify the desired permissions to be inherited by the file owner.
Generally speaking, setfacl -R should be used very sparingly it may break permissions auto-inheritance determined by Windows clients.
Alexander September 18, 2021 at 11:43 PM
Thank you very much for answering that fast...
I literally searched the whole time now to find what you just said. Have to admit that I failed - as it seems.
I am failing to understand how it could be right to swap given user rights in windows (screen shot) to group rights on the extended/NFSv4 ACL in TrueNAS.
After I set permissions via Windows, an additionally added user fails on gaining access to that folders. As soon as I swap the group rights for user rights by applying:
setfacl -R -x group:CHAOSTRUPPE\\$USERNAME:rwxpDdaARWcCo-:fd-----:allow $FOLDER
setfacl -R -m user:CHAOSTRUPPE\\$USERNAME:rwxpDdaARWcCo-:fd-----:allow $FOLDEReverything works as expected again.
Could you lend me a hint or a link to where I can read and learn about that default behavior or, even better, lend me a helping hand on achieving what I expect to be happening?
Because this is a real p.i.a. to be honest... Especially when the count of users in the environment is rising...
Andrew Walker September 18, 2021 at 10:09 AM
This is expected behavior with ID_TYPE_BOTH idmap backends. Is there actual functional impact?
Alexander September 18, 2021 at 8:51 AM
Latest TrueNAS 12.0 Stable release as of the day of writing this.
Details
Details
Assignee
Triage TeamReporter
AlexanderLabels
Impact
Time remaining
Components
Fix versions
Priority
LowKatalon Platform
Linked Test Cases, Katalon Defect Results, Katalon Studio Test Results
Katalon Platform
As soon as I set a user ACL via Windows File-Explorer and apply the ACEs to the directory, TrueNAS changes the given ACEs for USERS into ACEs with the GROUP of the username.
I tried it now several times.
Steps to reproduce:
TrueNAS connected to an Windows AD
Create a dataset for user homes.
Apply standard ACLs for homes
Connect to a user home in user context to let the folder be created
Go on a windows machine and log into an administrative account
Browse to parent directory of the user home (so users homes).
Change the Permissions of a specific user folder to explicitly contain FULL CONTROL rights for a user (via Properties of the Folder - Permissions)
Afterwards check permissions via getfacl on the command line
The command line returns the added rights for the group of the user, not the user itself
This seem to happen to all user rights.
They appear as group rights on the getfacl output.
See the attached screenshots