Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NAS-130338 / 24.10 / Allow overriding execute check in setacl in some cases #14112

Merged
merged 1 commit into from
Aug 7, 2024

Conversation

anodos325
Copy link
Contributor

When TrueNAS is joined to active directory it's possible that the AD administrator has created nested security groups in such a way that it becomes non-trivial to validate whether a user can gain access to a path by virtue of being a member of a particular group.

This is because the nested security groups are flattened only when resolving the groups for a particular user via getgrouplist(3).

Since nested groups only exist if directory services are enabled, this bypass raises a ValidationError if the server is in a standalone configuration.

We still default to checking access (previous behavior) because using nested security groups in this way is a security anti-pattern as it renders the effective permissions on filesystem paths very difficult or impossible to easily audit.

@anodos325 anodos325 added the jira label Jul 30, 2024
@bugclerk
Copy link
Contributor

@bugclerk bugclerk changed the title Allow overriding execute check in setacl in some cases NAS-130338 / 24.10 / Allow overriding execute check in setacl in some cases Jul 30, 2024
@anodos325 anodos325 force-pushed the relax-acl-validation branch from ccf1f25 to 81822a7 Compare August 6, 2024 13:53
When TrueNAS is joined to active directory it's possible that the
AD administrator has created nested security groups in such a way
that it becomes non-trivial to validate whether a user can gain
access to a path by virtue of being a member of a particular group.

This is because the nested security groups are flattened only when
resolving the groups for a particular user via getgrouplist(3).

We still default to checking access (previous behavior) because
using nested security groups in this way is a security anti-pattern
as it renders the effective permissions on filesystem paths
very difficult or impossible to easily audit.
@anodos325 anodos325 force-pushed the relax-acl-validation branch from 533a39b to 42fdd10 Compare August 6, 2024 16:15
@anodos325 anodos325 merged commit 292788c into master Aug 7, 2024
3 checks passed
@anodos325 anodos325 deleted the relax-acl-validation branch August 7, 2024 11:34
@bugclerk
Copy link
Contributor

bugclerk commented Aug 7, 2024

This PR has been merged and conversations have been locked.
If you would like to discuss more about this issue please use our forums or raise a Jira ticket.

@truenas truenas locked as resolved and limited conversation to collaborators Aug 7, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants