Hi guys,
for testing pourpose I copied from TrueNAS Core to Scale my server.
I have a share SMB on top of one dataset with childs datasets.
Something like this
On my old TrueNAS i can add a new group permission to one child dataset with out problem but with SCALE:
The issue is precisely as described in the error message. We have more robust validation in SCALE to prevent users from cutting out feet from under their users.
That is amazing on a âhome configurationâ but on enterprise environment itâs not a suitable solution.
We have more than 2000 security groups and hundreds of datasets.
How to manage it? I have to add all groups to all partens dataset?
On the end at root datasets should be added all security group???
I there a work aroud to repliace se funcion presente on TrueNas Core
I think you are misunderstanding the Unix permissions model (this is exactly same behavior on MacOS, Linux, FreeBSD, etc). Traverse checking is strictly enforced. Windows also has this concept, but for normal user accounts it is not enforced. Just set a non-inheriting ACE for domain users on each dataset mountpoint granting TRAVERSE rights.
Itâs not a home user vs enterprise thing. What you were doing before was subtly broken and weâre pointing it out forcefully now.
If your domain user lacks ability to traverse a path component access to the share will fail with EPERM. Itâs actually more secure than default in Windows. In windows someone could potentially set an ACE granting access to a path deep in the file tree and open up others to access it directly.
Let me clarify
My user is a member of domain users (iâm able to see the content of root dataset) but iâm also member of ProposalRW (with read and write permission)
Okay. I could probably loosen validation slightly in the next major release by adding the domain users group (RID 512) to the credentials we use to verify group permissions when joined to AD. This can still potentially lead to broken access to the share path for some cases (for example where the authenticated credentials are not a member of âdomain usersâ), but would allow things through in your situation.
By and large the largest permissions-related problem we have faced historically from end-users (both home and enterprise) is precisely this (not understanding the role of the execute bit on directories and cutting off access to their users).
Sorry but I donât know what youâre talking about.
ânext major release by adding the domain users group (RID 512)â
What do you mean?
Next major release would be Electric Eel (24.10) about to enter alpha.
To validate that ACL works as intended (for group entries) we generate a user token with UID that does not exist (and wonât exist) and the group being evaluated for the ACL (e.g. user with only that group). When weâre joined to AD itâs reasonable to assume that most accounts will also be members of âdomain usersâ and so this can also generally be safely added to the unix token.
Once we have a unix token we setresuid() to it and perform basic access checks for each path component to validate that it can chdir successfully into it.
TL;DR, once the change is in the error message wonât occur if someone who is a member of the group domain_users and the group being evaluated can access the path.
I have done some tests and from the command line, I can do exactly what I have always done. From this, I deduce that the restriction is only in the UI.
My question is:
Isnât it dangerous to force users to do certain things in the UI while the command line works as usual?
No. We donât do any validation on command line, but if you break it you get to keep the pieces.
@DesmoPR assuming you are managing your users and groups in AD could you create a transit group in AD for âdataset rootâ called âdatasetroot-tâ and assign that group read and no inherit access to dataset âroot datasetâ. Then create a âdataset proposalâ group called âdatasetproposal-mâ and assign that modify access with inherit to the âdataset proposalâ dataset. Then finally make the âdatasetproposal-mâ group a member of the âdatasetroot-tâ group in AD. That would allow users in the âdatasetproposal-mâ group to traverse the parent dataset without allowing them to see any of the data within in and only data within the sub-dataset. This is how I setup all my shares.
hi @Johnny_Fartpants,
I agree with you but the key point of the problem, in my opinion, is the forcing to manage permissions in a way that has never been done before.
I have a root dataset where all domain users can log in and then members of a specific group can edit data in a sub dataset.
You are right, Iâm managing truenas with AD.
Really thanks to the developer group for listening to the users!
Removing the selection is exactly like the previous version. Now it can be used in enterprise environment
