Share permissions

[tonycody]

My god, TrueNAS sharing permissions are so complicated that I can't even read them.

 

[tonycody]

Why did AFP set 2 paths? What do they mean?

Truenas really just makes the shared services that Linux provides available in the background. Why is it so complicated in the permissions area?

90% of people don't get it at first glance

 

[anodos]

The top item shows the share's path, the tree allows you to browse the filesystem and select a different path. Some parts of NFSv4 ACLs are complex because it's the nature of how they work, but they shouldn't be required for sharing via AFP. You can just use the POSIX mode editor to set what you need.

 

[emk2203]

I agree that this is complex, but actually less confusing than the permissions on Windows systems.

 

[anodos]

I agree that this is complex, but actually less confusing than the permissions on Windows systems.

The question is how much to hide from end-users / systems administrators. For the case of SMB at least, you have to -in some way- provide SMB ACLs to SMB clients. On Linux, Samba will write these to an xattr "security.ntacl". Since they're not enforced by the kernel, end users and admins may go merrily on their way without knowing what permissions are actually being enforced over the SMB protocol (unless you use an SMB client to view the ACL on the file). [This is, of course, more nuanced on Linux where Samba may try to map the NT ACL requested by the client into a POSIX1E ACL. NTACL->POSIX1E ACL conversion is necessarily lossy.] Depending on whether you're responsibly for the security of this at your day, or if it's a home file share, this _may_ be a good thing.

We take the alternate approach and present the permissions to the end-user. This opens up more potential for foot-shooting, but also allows admins to know how the server is actually configured. I believe some vendors make things easier by just opening permissions wide by default and make it "just work", but this is I believe somewhat bad if you intend to use it in a business environment.

 

[tim64]

We take the alternate approach and present the permissions to the end-user. This opens up more potential for foot-shooting, but also allows admins to know how the server is actually configured.
I believe some vendors make things easier by just opening permissions wide by default and make it "just work", but this is I believe somewhat bad if you intend to use it in a business environment.

There are all sorts of "business environments". In a business environment, where the admin wants to do everything himself/herself and knows all the underlying services/software/protocols (so he/she does not need explanations/documentation), there maybe is not very often a need for a GUI based NAS software.

Why not make it easy (for the inexperienced admin) and give the experienced admin the option to manually optimize everything?

 

[anodos]

There are all sorts of "business environments". In a business environment, where the admin wants to do everything himself/herself and knows all the underlying services/software/protocols (so he/she does not need explanations/documentation), there maybe is not very often a need for a GUI based NAS software.

Why not make it easy (for the inexperienced admin) and give the experienced admin the option to manually optimize everything?

It's not really a matter of "optimizing".

The sorts of issues that get you into the territory of ACLs are ones where you need to do things like:
* grant all members of GROUP-A read and write permissions
* grant all members of GROUP-B read permissions,
* grant all members of the ADMIN group the ability to do everything (no restrictions)

This is a very ordinary use-case. None of this is that complex in our GUI. Create a dataset, Create two groups for users. Add entries with MODIFY+INHERIT for Group-A, READ+INHERIT for Group-B, and FULL_CONTROL+INHERIT for Admins to the dataset.

If we didn't provide a mechanism to configure and reset these from the GUI, then users would end up having to rely on either shell commands or the ACL editor in a Windows client to achieve this. Over the years of doing this stuff, I've seen modifications through shell or Windows go wrong in a variety of ways (typo in commands, not fully understanding syntax, Windows admin not having permissions to fix permissions through client, etc).

 

[tim64]

It's not really a matter of "optimizing".

The sorts of issues that get you into the territory of ACLs are ones where you need to do things like:
* grant all members of GROUP-A read and write permissions
* grant all members of GROUP-B read permissions,
* grant all members of the ADMIN group the ability to do everything (no restrictions)

This is a very ordinary use-case.

I agree. Yes the above is a very ordinary use-case.

Well, maybe the inexperienced admin would think that "read and write permissions" are the same as "do everything". In the GUI there is no real explanation or help to understand this difference. And then you have "Group" and "@group" and if "@group" is selected, it means the "Group" field from the left column. Why not use the same wording on both sides? Same with "@user". And in the left "Group" field the help text shows "This group has the same permissions as granted to the group@ ", so it is not the same group, but a different group that only has the same permissions? Is this somehow important for the ordinary-use-case or only a not so good wording?

None of this is that complex in our GUI. Create a dataset, Create two groups for users. Add entries with MODIFY+INHERIT for Group-A, READ+INHERIT for Group-B, and FULL_CONTROL+INHERIT for Admins to the dataset.

Why bother with "INHERIT" when it is always enabled in the ordinary use-case? Hide it from the GUI and make it a default and let it be changed in "advanced-mode". And wouln't it be better if there would be an explanation of "Inherited", "Inherit only" and the other options?

And when the user wants to edit permissions/ACLS of a SMB share there is "Edit Share ACL" and also "Edit Filesystem ACL". Why are both needed for that ordinary use-case from above? And when the admin clicks on "Edit Share ACL", because he/she wants to change who (GROUP-A or GROUP-B) has read-write access to the SMB-share, the next page shows things like a cryptic-"SID" without explanation/help and only a link to some Microsoft page that does not really help for that use-case.

Its all the small details that together can become confusing for a new user/admin. It starts with, how the GUI elements are shown and grouped, where borders, input fields and buttons are placed and continues that you can not select "group-a" or "group-b" if you choose "@group" and not "Group".

A new/inexperienced admin maybe just wants to (at first) set up that ordinary use-case from above and does not want to have to understand microsoft-sids, how freebsd internally handles nfs, samba, why he has to select "Edit Filesystem ACL" (and not "Edit Share ACL") when he wants to edit the groups/users that have access to a SMB-share, etc.

Maybe these are all small and unimportant details for you, because you understand the system so well. But please try to look with the eyes of users/admins, who never have used TrueNAS/FreeNAS before and who want a NAS-product that is reliable (based on ZFS) easy to understand/use and that makes their life easier from the beginning (and later allows the freedom to change the settings in detail, if needed).

 

[anodos]

I agree. Yes the above is a very ordinary use-case.

Well, maybe the inexperienced admin would think that "read and write permissions" are the same as "do everything". In the GUI there is no real explanation or help to understand this difference. And then you have "Group" and "@group" and if "@group" is selected, it means the "Group" field from the left column. Why not use the same wording on both sides? Same with "@user". And in the left "Group" field the help text shows "This group has the same permissions as granted to the group@ ", so it is not the same group, but a different group that only has the same permissions? Is this somehow important for the ordinary-use-case or only a not so good wording?

Basic permissions sets are "READ, MODIFY, FULL_CONTROL". Fairly self-explanatory here. I think. Perhaps a better option for GUI would be to hide the ability to change owner under an advanced screen and put the owner name next to owner@ in the GUI string "owner@ - bob". This is more of a GUI concern. You can file an improvement / enhancement bug on our jira instance for the webui team.

Why bother with "INHERIT" when it is always enabled in the ordinary use-case? Hide it from the GUI and make it a default and let it be changed in "advanced-mode". And wouln't it be better if there would be an explanation of "Inherited", "Inherit only" and the other options?

GUI shows the current on-disk ACL for the path being viewed. Files always have an ACL present. So there should be enough information for the admin to understand what's here. Ditto on filing enhancement request for improving explanation. Default for new ACL entries is MODIFY and INHERIT, but POSIX mode when represented as an NFSv4 ACL has no inheritance bits set and has an "advanced" permset. I can maybe modify output from filesystem.getacl here to indicate the POSIX mode more clearly in the ACL editor, but discarding information about current ACL isn't a great option.

And when the user wants to edit permissions/ACLS of a SMB share there is "Edit Share ACL" and also "Edit Filesystem ACL". Why are both needed for that ordinary use-case from above? And when the admin clicks on "Edit Share ACL", because he/she wants to change who (GROUP-A or GROUP-B) has read-write access to the SMB-share, the next page shows things like a cryptic-"SID" without explanation/help and only a link to some Microsoft page that does not really help for that use-case.

This one is rather tricky. The share ACL is written to the backend using SIDs. This is dictated by protocol and the necessities of idmapping. If winbindd is running the GUI should resolve the SID into a username / group. I could possibly resolve these using the winbindd_idmap cache when the SMB service is stopped, but it doesn't do much if they're uncached. The share ACL is used in cases where users want to configure "access based share enumeration". So there's technically a reason for them being present. I can think some of how to simplify the share ACL administration.

Maybe these are all small and unimportant details for you, because you understand the system so well. But please try to look with the eyes of users/admins, who never have used TrueNAS/FreeNAS before and who want a NAS-product that is reliable (based on ZFS) easy to understand/use and that makes their life easier from the beginning (and later allows the freedom to change the settings in detail, if needed).

Not small details. This sort of feedback is helpful. Feel free to file a jira ticket about it so that the UI team can give the implementation more consideration.