Super User created with wrong permissions (ToS 5.1)

[StephenNaylor]

I believe that the Super User is being given the wrong permissions when ToS 5.1 (and 5.0) is installed.

This is what the ToS help says about default permissions...

"The TOS system starts with the following default groups:

admin: All members of this group are administrators, and so they have administrator permissions. This group cannot be deleted.
allusers: All users who are not administrators are members of this group. This group cannot be deleted."

As I read the above, it is saying that the admin should not be a member of the allusers group.
It also implies that if a TOS User is added to the admin group that they would be removed from the allusers group.

When I installed ToS 5.0 my SuperUser was added to both the Admin and the allusers group.

I have just rebuilt my system to fix the 2GB system partition issue and my 5.1.37 install also added my SuperUser (i.e. the first user created) to both groups.

Based on what the help says I believe that this is wrong. Administrators should not be a member of allusers.
Alternatively the help is wrong and needs updating.

Can someone from TerraMaster clarify this point please?

[TMroy]

The TOS HELP is wrong, the superuser belongs to Alluser group. we will modify it.

[StephenNaylor]

Thank you. That would be helpful.

It would also be good to get a better explanation in the help content about how groups should be used to control permissions. I've not set up user groups since ToS 3 and i'm currently finding it counter intuitive.

Can you confirm whether the following understanding is correct.

1. Any folder where you want any user to have access must have "allusers" set to "read" or "read/write"
2. You then use other groups to deny access to that shared folder.

Example:
I create 2 Users, "Parent1" and "Kid1"
I create a group called, "Parents" and add "Parent1" to this.
I create a group called, "Kids" and add "Kid1" to this
I create a Shared Folder called, "Parents Films" to hold films with certificate 15 and 18 content. I set this to have permissions controlled by User Groups.
I give the "Parents" group read/write access to "Parents Films"
I give the "Kids" group Deny access to "Parents Films"
Allusers defaults to "Deny"

If I log in with Parent1 at this point I cannot access the "Parents Films" folder.

I am assuming that this is because "allusers" is blocking the access. Is this correct?

so, to get my permissions working correctly I would need to change "allusers" access on "Parents Films" to read/write. Is that correct?

The side effect of this is that any new user I add to the system would automatically have "read/write" access to "Parents Films" unless I also add them to the "Kids" or "Parents" group.

If the system works the way i've describeda bove then it feels like the "Parents" group is probably redundant. I don't actually need it to allow access as that is controlled by "allusers". The only group I actually need is "Kids" which would be used to remove access. Do I have that right?

[Gremlin]

[at=StephenNaylor post_id=27962 time=1687425997 user_id=7043][/at]

The logic of your example seems correct.

The 'actual' in practice sounds wrong.

English is my first language (Canadian is my second) and I'm confused. Who knows what TMSupport will make of it.

As I've not actually setup/checked multiple users for any active purpose I will have to experiment.

[StephenNaylor]

There is something seriously broken with User Group Permissions.

To test my theory that the allusers group is blocking access to my shared folders I did the following...

1. In Windows I tried to map a drive. I could only see the Public folder and the home drive of my user.
2. In ToS I edited the "Parents" group and gave "allusers" Read/write access to it and saved the change.
3. In Windows I tried to map a drive again. My expectation was that I would now be able to see my Parents Group and map to it......

That's not what happened. What actually happened is that I can now see, Public, the home drive of my user and "General" which is another group which I have set up on my NAS.

So, giving "allusers" read/write access to my "Parents" shared folder has actually enabled me to view a different group via SMB.

Can someone from support provide some guidance here please?

[StephenNaylor]

Regarding my last post, I note the following from the release notes from ToS 5.1.40:

6. Fixed the issue where permission configuration was incomplete when creating a shared folder.

That sounds in the ballpark of the issue I saw. Is there any more information on that particular issue so we can understand what problems it was causing?

[Gremlin]

[at=StephenNaylor post_id=28211 time=1688489083 user_id=7043][/at]

I have tried to follow this thread (albeit a bit one sided!) as I also have difficulty with permissions. Couple of things I have noticed:
First for ease I define superuser as S-U. My personal Login as ME1.

When the system is initialised a GROUP is also created called "S-U" (taking the typical root gid) as well as the user "S-U".

When I access the system as S-U, files are created with UID S-U and GID S-U.

When I access the system as ME1, files are created with UID ME1 and GID "allusers". "allusers" can, at face value, read/write all my files. This is NOT what I want!

Looking at /etc//passwd all users are created with the same group id (4) ie allusers.

It appears that a lot of use may be made of Access Control Lists (the little '+' nest to permissions listing for those interested) or POSSIBLY TM's version of acl. I don't know. But acl do 'tack-on' permissions in various ways which may, or may not, amend the obvious permissions.

At the simplest level, I would expect the user 'ME1' to be in a group 'ME1' on creation and then the system admin can choose which additional groups/users can access ME1 files and or which group(s) user ME1 is added to.

More investigation is required, but without some input from @TMSupport, it will take longer

[Gremlin]

Sorry about the formatting my last post. Something is eating n/lines!

Anyway, subsequently, I can see that Shared folders, where I have explicitly set group permissions are (apparently)
being properly assigned permissions when I run 'getfacl' to show the acl permissions assigned to the folder.

e.g. I have a folder called 'BACKUPS' which is set to give rwx rights to the group 'BACKUP' and nothing else. However, although I am a member of the group 'BACKUPS', I cannot access that folder.

Neither can I access that folder when it is explicitly assigned group permissions for 'allusers' although the acl correctly recognises the change in group permissions.

Neither can I access that folder when it is explicitly assigned group permissions for 'admin' group.

It appears that I can only access the folder when I assign a my specific user permission.

Based on this limited look I can only infer that, although the acl appears correct, something is broken in the implementation and application of the acl.

[StephenNaylor]

@Gremlin Thank you for investigating and confirming that group permissions are not working.

TerraMaster support. Please can you comment on this matter. A broken user permission system is a significant and fundamental failure of the operating system that must be addressed.

[TMzethar]

On TOS5, user permissions take precedence over user group permissions. There is currently a slight issue with group permissions. We will fix and optimize permissions in future versions.