Advanced ACL Permissions

[TMroy]

What are Advanced ACL Permissions?
Advanced ACL (Access Control List) permissions refer to a storage space permission management feature developed by TerraMaster in new TOS 6 system. Compared to permissions in traditional Linux systems, Advanced ACL permissions not only provide basic read-only, read-write, and prohibit three common permissions, but also add 13 additional permissions that can be customized by users. This makes the storage space permission management more flexible and resilient, able to meet users' more diverse needs.

What are the functions of Advanced ACL Permissions?
Advanced ACL permissions have the following functions:
1. Apply to TOS system users and user groups.
2. The 13 newly added permissions are categorized into three main categories: Administration permissions, read permissions, and write permissions.
3. Administration permissions include modifying permissions and obtaining ownership.
4. Read permissions cover operations such as traversing folders/executing files, listing folders/reading data, reading attributes, reading extended attributes, and reading permissions.
5. Write permissions include creating files/writing data, creating folders/appending data, writing attributes, writing extended attributes, deleting subfolders/files, and deletion.
6. Administrators can enable or disable any of the above settings based on specific requirements.

What are the advantages of Advanced ACL Permissions?
TerraMaster's Advanced ACL permissions break through the traditional limitations of read and write permissions, providing more flexible permission settings. Administrators can separately configure Administration permissions, read permissions, and write permissions for users or user groups. Through Advanced ACL permissions, users can enjoy higher flexibility in usage while ensuring data security. Specifically, Advanced ACL permissions allow administrators to fine-tune permissions for users or user groups based on specific needs, ensuring data read and write access while preventing accidental deletion of data. This flexible approach to permission management makes TerraMaster's Advanced ACL permissions a powerful safeguard for enterprise data security.

How to use Advanced ACL Permissions?
To use Advanced ACL permissions for storage space settings, please follow these steps:
1. Open the TOS desktop and find the Control Panel.
2. In the Control Panel, select the "Permissions > Shared Folders" option.
3. In the shared folder list, select the folder for which you need to configure permissions.
4. Click the "Edit" button for the selected shared folder and select "Permissions".
5. On the permission setting page, select the "Customize" option.
6. In the pop-up configuration list, check the boxes for the desired options.
7. Click the "Apply" button to save and apply the changes to the permissions.
After completing the above steps, you have successfully set up Advanced ACL permissions for the storage space. Please note that the specific steps may vary depending on the version and configuration of the TerraMaster system. If you have any questions or concerns, we recommend referring to the official Teamsun documentation or contacting technical support for more detailed information.

Who are Advanced ACL Permissions suitable for?
Advanced ACL permissions are suitable for the following users:
Enterprise users with multiple departments or workgroups who require coordination and data sharing among members. Due to the more flexible permission settings offered by Advanced ACL permissions, administrators can fine-tune permissions for each user or user group to ensure data security while enhancing usage flexibility. Therefore, Advanced ACL permissions are particularly suitable for enterprise users to meet their data security and usage needs.

[tanktarta]

I am trying to understand the behaviour of groups and ACL permissions on shared folders. Something doesn't seem right.

If I choose to control the permissions of a Remote Folder using Groups Only, it doesn't appear to work. My clients cannot access Remote Folders for either read, or read+write. However, If I add individual user permissions, access is allowed.

It is also ambiguous as the order of precedence. If a user has permission because a group they are in has access, does this override a Deny they might have. And is the reverse also true? If there are NO specific user permissions, is this when the group permission should take precedence?

It might make sense if you could de-select any user specific permission entirely, but you cannot. Once a user permission is selected, you only change it to another category, not remove it (if this makes it the default).

I am actually joined to a domain and using domain users and groups, but I see the same effect with local users and groups.

All of this is on TOS 6.0.420. Apologies if this is already fixed!

[TMzethar]

The mounted folder is not a local folder, and it is not yet possible to have user group permissions take effect.
The current rule (TOS 6.0.426) is that user permissions take precedence over group permissions. This will be changed and optimised in a future release.

[tanktarta]

The mounted folder is not a local folder, and it is not yet possible to have user group permissions take effect.

Sorry I wasn't clear. I should have said Shared Folders. I am not trying to set permissions on a remote mounted folder on the NAS. I am trying to make group permissions work at all for shared folders on the NAS so clients accessing as users that are part of those groups can see them without having to set individual users permissions. Say I have 10000s of user. I don't want to set every single permission of every single user individually.

Also. it is fine that user permissions override group permissions, but then how do you "unset" a user permission. When you first create a Shared Folder, ALL the permission radio buttons are OFF. Once one has been click and applied it cannot then be removed, it can only be set to DENY, READ, READ+WRITE or CUSTOM. There is no radio button for "Use Defaults", and you cannot de-select a permission.

If as you say user permissions take precedence, and I have set a particular share to have permissions for a particular user, but then I want to change that so that only a group permission is used, what do I change the user permission to? If I set it to DENY, that will take precedence? I could set it to READ, or READ+WRITE, but that's not what i want, i want it to be controlled by the group permissions. CUSTOM cannot be set with no entries to reset it to the default, so what are my choices here? The same applies to Domain Groups and (Local) User Groups, how can it be configured if I only want to make use of Domain Groups for control of permissions.

In short ..

* Setting (domain) user permissions works just fine.
* Setting (domain) group permissions does not work at all for me. If I set a shared folder to just have group access. Group members cannot access.
* Even if it did work, it seems impossible to maintain in a manner that makes sense, as there is no way to express that you wish to to use the defaults of whatever principal type takes precedence.

It may help if you could explain exactly how the order of precedence should works for "Users", "User Groups", "Domain Users" and "Domain Groups" and within each of those how "Deny", "Read", "Read+Write" and "Custom" permissions affect each of those. I have looked for but cannot find this information in the forums or your documentation.

[Gremlin]

Since this subject has been raised before by various users, it would be interesting to get a definitive reply rather than "it's going to be done". Perhaps a 'road map' ... by Tos7, Tos8

It seems to me that different groups of developers are using the permissions for their 'own devices' to make their part of the software suite function in the way they want. Do we all want/need "Media" group? Do we want every user in "allusers" group. I do not. I may want a 'user' to ONLY be part of a specific group - for example a 'machine user' that only is used for performing "backup" tasks (in a "BACKUPS" group). This "user" would never be a real person logging in on a terminal. I would say that, generally speaking, defining set groups/users for specific purposes is all very well, but it needs to be very clearly explained what the purposes of those might be and what functions they relate to.

It has seemed in previous releases that someone has made the attempt to correct what have been perceived as "issues" but that, later, this has been reversed (or changed in another way) so that we (the customers!) are left trying to figure out what is going on. Sometimes inconsistencies in even the manner that @TM thinks things are working have been pointed out; only to be met by silence.

As I have said previously, I am no expert in the workings of 'acl' but I know enough, I think, to know "it feels wrong"; and 'domains' add a layer of complexity I don't even want to think about at the moment

[tanktarta]

Since this subject has been raised before by various users, it would be interesting to get a definitive reply rather than "it's going to be done". Perhaps a 'road map' ... by Tos7, Tos8

Ah .. I am new to TM, so have no idea of what came before really. I only briefly used TOS 5 before updating and hadn't dug this deep. In fact wanting better ACLs was exactly why I installed TOS 6.

'domains' add a layer of complexity I don't even want to think about at the moment

Heh yeh. On the plus side, everything else about domain integration seems to work well. So good job TM on that bit. Joined domain flawlessly, all the users and groups I want are listed, and remote shares are browsable and just work in all my clients. But, only if specific READ or READ+WRITE user permissions are used.

For all I know this is just a bug, or maybe an artifact of my not so smooth upgrade. Either way it would nice to know. This is important to anyone above home user level.

[tanktarta]

Progress! I have got the configuration I want, but it involved going to the shell. And the change isn't permanent. Upon reboot this gets re-written (I assume from TOS internal database). But it does prove at least what I want is possible.

First thing to look at is getfacl. Running this command gives ...

Code: Select all

superuser@terra:~# getfacl /Volume1/public/
getfacl: Removing leading '/' from absolute path names
# file: Volume1/public/
# owner: superuser
# group: 900
user::rwx
user:superuser:rwx
user:bin:rwx
user:sys:r-x
user:man:r-x
user:guest:---
user:transmission:rwx
user:plex:rwx
group::---
group:superuser:rwx
group:bin:r-x
group:sys:rwx
group:adm:r-x
group:disk:rwx
group:lp:r-x
group:redis:rwx
group:crontab:r-x
group:allusers:---
group:admin:rwx
group:SOUTHPARK\\home\040users:rwx
group:SOUTHPARK\\work\040users:r-x
mask::rwx
other::---
default:user::rwx
default:user:superuser:rwx
default:user:bin:rwx
default:user:sys:r-x

Now there is a load of stuff in there that I am guessing TOS adds itself. I want to give "SOUTHPARK\home users" read+write access, and "SOUTHPARK\work users" read only access. I can see these rules in the ACL list above. But yet I can't access as a user that is part of the "home users" group.

I couldn't really see any good reason why a lot of those default linux users like man. and sys needed access either. So I tried resetting the ACL entirely.

Code: Select all

# setfacl -bR /Volume1/public
# getfacl /Volume1/public/
getfacl: Removing leading '/' from absolute path names
# file: Volume1/public/
# owner: superuser
# group: 900
user::rwx
group::r-x
other::---

And then added back the group(s) I wanted.

Code: Select all

superuser@terra:~# setfacl -R -m g:"SOUTHPARK\\home users":rwx /Volume1/public
superuser@terra:~# getfacl /Volume1/public/
getfacl: Removing leading '/' from absolute path names
# file: Volume1/public/
# owner: superuser
# group: 900
user::rwx
group::r-x
group:SOUTHPARK\\home\040users:rwx
mask::rwx
other::---

But it still didn't seem to make much of a difference. I could not see or connect to the samba share. After trying a few more things, I eventually realised that the problem may actually be samba itself, not the file access controls.

That lead me to this section in /etc/samba/smb.conf.

Code: Select all

[public]
path = /Volume1/public
browsable = yes
writeable = yes
write list = transmission,tanktarta,superuser,admin
valid users = admin,transmission,tanktarta,superuser
hosts allow = *
vfs objects = full_audit recycle catia fruit streams_xattr
fruit:time machine = yes
catia:mappings = 0x003a:0x2236,0x003f:0x0294,0x002a:0x2217,0x003c:0x276e,0x003e:0x276f,0x0022:0x02ba,0x007c:0x2
223,0x005c:0x29f9

Note, the write list and valid users (in particular). First I tried to comment out these two lines, and restart the service.

Code: Select all

systemctl restart smbd

But that just made TOS rewrite smb.conf exactly as it was. So instead, I commented out those two lines again and instead did ..

Code: Select all

smbcontrol all reload-config

which let me try out the configuration without TOS rewriting it. And it worked! My client can now see the Public share in Network Neighbourhood and access it witth read+write permissions logged on as "SOUTHPARK\tanktarta".

The problem of course is, as soon as I change any configuration in the UI and/or reboot. It is going to stop working.

So while I think there are still problems with the permissions user interface, and how default states can be set, it looks like the automatic configuration of smb.conf is somehow at fault as well.

Perhaps TOS needs to not configure write list and/or valid users at all. So far, the ACL permissions seem to suffice. Users who are NOT part of "home users" cannot access t he share.

Or maybe it needs to be writing group names in there too. However, a quick look through the manual for smb.conf seems to suggest there no such thing as valid groups exists, or some special syntax for specifying groups.

Hopefully this helps someone track down exactly what is happening.

[tanktarta]

However, a quick look through the manual for smb.conf seems to suggest there no such thing as valid groups exists, or some special syntax for specifying groups.

Oh, actually this is not true. It looks like +<domain>\<group> can be used. So i suspect TOS needs to be doing that instead of what it is currently doing.

[TMzethar]

Regarding the problem that group permissions don't work and the problem that you can't cancel the permissions by setting them to null, we will optimize it in the future TOS 6 official version.

[tanktarta]

Regarding the problem that group permissions don't work and the problem that you can't cancel the permissions by setting them to null, we will optimize it in the future TOS 6 official version.

Great to hear!