I’ve encountered a difference in SMB share behaviour between CORE and SCALE, particularly when using Active Directory (AD) for permission management with nested AD groups.
Scenario
In CORE:
Create a dataset named Shared123.
Assign permissions:
testgroup-t:
Permission: Read
Flags: No Inherit
testgroup-m:
Permission: Modify
Flags: Inherit
For Directory Access Control:
To restrict access to a subdirectory Shared123/Finance so that only specific users can access it without seeing the contents of Shared123:
Create a new AD group testgroup_finance-m.
Make testgroup_finance-m a member of testgroup-t.
This setup ensures that members of testgroup_finance-m can traverse into the Finance folder without viewing other contents of Shared123. This configuration works flawlessly in CORE and has done for the last 8-10 years.
Issue in SCALE
When replicating the same setup in SCALE:
Users can see all files and directories within Shared123 even though they can’t access them.
Solution Identified:
Adding the line hide unreadable = yes in the share configuration resolves the issue, making the behaviour consistent with CORE.
So, my question is why has this behaviour changed from CORE to SCALE? Is it a bug, an oversight, or is there a specific reason for this change?
Note: This query is not about Access-Based Share Enumeration. I mean enabling or disabling makes no difference to the outcome.
Evaluating the READ_ATTRIBUTES permission on stat() calls would impose too much performance penalty in kernel potentially making us have to fallback to various slow-paths in kernel all the time. You’re welcome to set that auxiliary parameter, but it will impact among other things dir listing performance.
There is no real security impact for this difference in behavior.
Many thanks. Why the difference between CORE and SCALE. I can’t see the hide unreadable = yes option present in CORE but it’s clearly doing it or something similar?
How so? Having the ability to allow certain users to access certain sub-directories while not seeing the entire contents of the share. Open to other suggestions on how to accomplish this however I’ve become very happy and confident with my existing setup in CORE. Also would be a massive pain to change if I ever upgraded to SCALE.
The problem you’re describing is whether a user should be able to read basic file attributes of a file if they have not been explicitly granted READ_ATTRIBUTES permission. FreeBSD kernel has this check, linux kernel does not. The results of permissions check informs whether or not a particular file appears in a directory listing via syscalls. It’s lower level than Samba and 100% unrelated to AD or nested groups.
You could always set the auxiliary parameter and eat the performance hit c.f. manpage:
Please note that enabling this can slow down listing large directories significantly. Samba has to evaluate the ACLs of all directory members, which can be a lot of effort.
Otherwise since it’s only a cosmetic issue you can just deal with it. Changing linux kernel behavior to introduce a potentially blocking permissions check in stat / dir listing is unacceptable.
Hmm very interesting and many thanks for your time and explanation. I still imagine this will be a big issue with enterprise environments either upgrading to SCALE or adopting TrueNAS.
No. This works as intended. The only functional impact we’re talking about is whether files appear in a directory listing (not whether you can actually open them for reading).
Well, it cuts both ways. We also get users complaining in core that files aren’t visible.
In the big picture, it’s not like it’s terribly confusing for users to say “you have access to this directory in this folder but nothing else”.
Though if you’re doing this many levels deep, it sounds pretty unmaintainable. Better to flatten / redesign the hierarchy (speaking in very broad terms).
Really appreciate your thoughts and assistance on this but I do have to disagree with the impact it will have. I can just visualise the support calls coming in saying why can’t I access folder1 and folder2 but I can access folder3 and we say that’s just how it is.
And the irony being that Linux is just a kernel whereas FreeBSD is an OS.
Enterprise, I imagine, would also just toss more electricity at the issue if absolutely necessary.
I’ve seen this directory structure several times; (above my pay-grade) but I imagine they set it up that way because I can see it working well for ‘accounting’ and ‘design’ teams to share the same “project” directory structure; which I imagine works well for archiving. Seems a pain to set up a different dataset for each group and then have to have two archives for each backup. “acounting_xyz” “design_xyz”
Not to mention I’m sure you can script the archiving process …“get design & accounting directory then…” but I’ve seen ‘projects’ get canceled before one or the other team gets involved–“no funding” etc.-. So, this would essentially cause you to have a minimum of three different archiving schemes for just this scenario alone.
“Boss, I’m lost in IFs; we need to flatten our folders!”
“Betty will have your butt if you mess with her team’s productivity!”
I think from an Archive perspective you could probably get away with a flat permissions structure essentially one group to rule them all per dataset/share. However on a live system not so much. In my environment each ‘group’ gets their own dataset/share so that we can compartmentalise them and assign specific quotas etc. However within that group there may be 20-50 people that have access and naturally not everyone should have the same level of access as different information will have different classifications etc. Managing hundreds of datasets/shares is already fun enough but having to break that down even more ie creating more datasets/shares for every level of access would just be unmanageable.
If hide unreadable = yes is important to your use case, then as part of a NAS conversion from CORE to SCALE, I’d also prepare and plan for a sVDEV addition.
That way, the impact of overhead with SMB checking permissions becomes so de minimus (because the sVDEV is so fast) that even large directories are unlikely to take long to render. In other words, throw a bit of money at the problem to make it go away.
An additional bonus is the small file performance will also go through the roof.
