Smb share + ACL permission and Windows AD

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

List dataset

  1. dataset root
    1. dataset proposal

List acl

  1. Domain admin R/W, Domain User R
    1. dataset proposal - Problem ACL

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.

1 Like

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

List dataset

  1. dataset root
    1. dataset proposal

List acl

  1. dataset root + Domain admin R/W, Domain User Read Only
    1. dataset proposal + ProposalRW

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.