User and group broken permissions

GUI Network Settings configures Samba's read and write lists for the share.  With these Samba lists, as documented in the man page that if a user is in both the read list and the write list then they will be given write access.  So if the user is a member of a group in the write list, he will have write access to the share, regardless of whether or not he is in the read list.  The GUI certainly does a poor job of making that clear, and I agree that needs to be improved.

For GUI File Access, that just changes permissions on the root of the share.  If you have a pre-existing folder that test_user has write access to, then he will continue to have write access to that folder even after changing his GUI File Access to read-only.  Perhaps that's what's tripping up some of your test cases?

Now it gets even more clear

In fact, I was trying on same files, created on previous access rights

I did try on new created files whenever I change user access rights, and things work as you described

1- no way to give a user exception over its group, unless no access rights are specified to the group

2- point 1 can be fixed through windows as I understand

3- access rights are not reset at file level when we change rights for an existing user

This is a bit limiting and confusing in the GUI

At least now, I understood how things are setup

Two questions:

- when I change a user rights, how to force a rest of permissions at file level for all existing files/folders in the share?

- why the NAS implementation does'nt respect the Samba protocol: user access rights should always take precedense on group rights ?

---

chopin70 wrote:

 

One question: when I change a user rights, how to force a rest of permissions at file level for all existing files/folders in the share? 

---

You can do that from the GUI File Access area, by clicking on the RESET tab on the left, then clicking the "Reset permissions" button.

---

chopin70 wrote:

 

- why the NAS implementation does'nt respect the Samba protocol: user access rights should always take precedense on group rights ?

 

---

Samba is an open-source implementation of the SMB protocol.  But this has nothing to do with the SMB protocol.  The GUI Network Access tab configures simple share access lists, which are enforced by Samba -- not user and group rights.

Ok, I am better understanding things now

Still one question:

Reset file permissions: it will reset the permissions configuration defaults and apply them instead of applying the permissions as they are configured

It means, we need to reconfigure user access rights from scratch. As I understand it, after a reset, I am again going to change the user rights to what I want them. So, I am back to starting point: the existing files will keep the access rights done by reset and not the new rights I am giving to the users

If I follow this logic, the only way to get proper rights is:

- format NAS

- setup groups and users

- populate the NAS with files

- never change permissions for an existing user after that otherwise existing files will keep previous access rights of the user

What should be needed is:

- redesign the GUI so that it is clear we cannot setup a user differently than its group: still, it is a really restricted way to setup groups and users, but at least we have no more confusion (ro user of a rw group)

- provide a way to properly apply the configured users permissions to all existing files, or do it automatically when we change permissions for an existing user

- provide a way in GUI to add exceptions to users in a given group

I hope you can enlighten me if I am still getting things wrong

---

chopin70 wrote:

 

Still one question:

Reset file permissions: it will reset the permissions configuration defaults and apply them instead of applying the permissions as they are configured

It means, we need to reconfigure user access rights from scratch. As I understand it, after a reset, I am again going to change the user rights to what I want them. So, I am back to starting point: the existing files will keep the access rights done by reset and not the new rights I am giving to the users

 

---

Oh, you're absolutely right.  I thought that option was added some time ago, but looking now I see that it never was.  So, currently, the only good way for you to recursively reset permissions is to do it from Windows.

1) Log in to the NAS as admin

2) Right-click on the Share, and go to Properties

3) Switch to the Security tab

4) Make sure the permissions are configured how you want them to be on all the share contents

5) Click the Advanced button near the bottom of the windows.

6) Click the box next to "Replace all child object permission entries ..."

7) Click Apply

---

chopin70 wrote:

 

What should be needed is:

- redesign the GUI so that it is clear we cannot setup a user differently than its group: still, it is a really restricted way to setup groups and users, but at least we have no more confusion (ro user of a rw group)

---

That's not exactly true.  You can set up a user differently from his groups, as long the user-specific exception is to allow write access.  So, if his group is read-only, but the user allows write access, then it will work.

---

- provide a way in GUI to add exceptions to users in a given group

Samba simply doesn't support read-only user exceptions from the share access side of things.  That's probably because it's unusual to say "everybody in jack's group gets read/write access to the share, except jack".  It's much more common to say "everybody in jack's group get read-only access to the share, and only jack can write to the share".  However, one way to effectively do that would be to just add a new group, with your desired read-only user removed from that new group.

Thank you again Skywalker

Your last 2 posts do resume and answer all questions

I just hope there will be an update to make all through GUI (Apply recursively user permissions, remove option to set a ro only user in a rw group...)

I still wonder about one option:

- in "File Access" Security tab: we can actually setup Folder Owner and Folder Group differently from the corresponding user and group. Which config will take precedense in that case?

exp:

Folder Owner (new_user): rw

Folder Group (new_group): rw

new_group: ro

new_user: ro

I know it is no sense as we "should" set same permissions for Folder Owner and new_user; and respectively for new_group and Folder Group, however the GUI does offer thiese 2 contradictory choices. Which one will have precedense ? And maybe it is a good idea to remove this redundancy from GUI

---

chopin70 wrote:

 

I just hope there will be an update to make all through GUI (Apply recursively user permissions, remove option to set a ro only user in a rw group...)

 

 

---

@I posted this in the idea exchange, so people who want these features can vote for them.  chopin70 you might want to check the links and click on the up arrow.

https://community.netgear.com/t5/Idea-Exchange-for-ReadyNAS/Recursively-reset-file-ownership-and-permissions-from-the-admin/idi-p/1114072#M461

https://community.netgear.com/t5/Idea-Exchange-for-ReadyNAS/Ability-to-explicitly-deny-user-share-access-from-Web-UI/idi-p/1113840#M457

---

chopin70 wrote:

I just hope there will be an update to make all through GUI (Apply recursively user permissions, remove option to set a ro only user in a rw group...)

 

We may be able to make things behave more naturally, regarding the RO user in an RW group issue.  We've proposed a change to the Samba team (here) that would allow an individual user setting to have priority over a group setting, so we'll see what sort of feedback we get.

---

I still wonder about one option:

- in "File Access" Security tab: we can actually setup Folder Owner and Folder Group differently from the corresponding user and group. Which config will take precedense in that case?

---

 

These are analagous to the built-in CREATOR OWNER and CREATOR GROUP Windows ACEs, which get used for permission inheritance.  On Linux/UNIX, they must always exist, and should be configurable.

Thanks a lot for all your detailed feedback and information so far!

Everything is clear, many thanks.

About the way I setup groups: I will take the habit of creating ro and rw groups for every share, and add users to different groups until things get modified at the GUI and eventually SAMBA level

I tested the 6.5.2-T500 Beta 2 firmware since I saw in change history this entry

[Beta 2] Changed SMB share access control to give rights assigned to individual users higher priority than group rights.

Created:

- share: "new_share"

- group: "new_group" with r/w access to the "new_share"

- user: "new_user" member of "new_group

Test scenarios:

1- new_user: nothing checked for r/w will give it same credentials as his group: r/w in this case

2- new_user: r/o access to new_share will actually give it the proper exeption, that is r/o

Also, I noticed that the credentials are now applied to root fies, folders and subfolders when they are changed in the GUI. The old credentials are immeadiately replaced on every file in the share

Things seem now more consistent without contradictions. Admin is also always forced to be r/w in GUI

To be improved:

One last thing remain: adding an extra box mentioning either "no access"

- If "no access" is chosen: no read or write permissions will be given to the user or group

- If nothing selected, user willl inherit from group as expected

Home someone else can confirm the good news implemented in Beta 2

Many thanks to the NAS dev team

I wish I had seen this earlier.  I disagree that the implementation of user right always overriding group rights is the "correct" one, at least in the examples given.  "RO" is a granting of permission to read and no permission to write given or taken, which is different from an explicit deny for write, but you want it treated that way.   Having explicit allow and deny to read and write independently is the only way you can please everybody.

---

Sandshark wrote:

"RO" is a granting of permission to read and no permission to write given or taken, which is different from an explicit deny for write.

---

You're describing "R", not "RO".  Ready-only ("RO") is indeed an explicit write denial in every computing context that I'm familiar with.

I noticed that the windows option : "apply these permissions to objects and/or containers within this container only" is not affected when changing permissions in GUI

I had it ticked by default on some shares. That's what caused new files/subfolders no inheriting proper permissions from the share

The key here is the word "only", which won't apply defined permissions to child objects created

Applying permissions in GUI won't propagate to child objects if this option is ticked. I won't aware about the "only" part of that sentence.

---

Skywalker wrote:

---

You're describing "R", not "RO".  Ready-only ("RO") is indeed an explicit write denial in every computing context that I'm familiar with.

---

The ambiguity of it is why neither Linux nor NTFS use it and why Netgear probably shouldn't either.  Since a ReadyNAS has multiple access methods, how does the granting of "RO" attributes via Samba affect a user that is accessing via another protocol?  If they don't behave in the same way (and since Linux doesn't assign individual user rights for files except for the owner, I don''t think they will), then there may be an illusion of protection that is not really there (unless Samba is the only enabled protocol).  Apparently NFS does use the term "Read Only".  How does it behave under these conditions?