RN214 File creation using Windows 10 SMB

I can't say, because my 312 does not act the same way. And you are sure you've removed user mb795b from the "users" group?  I don't know why you'd assign ownership of a share to "admin", but I did something similar to what you did just to see what happens.

I created "user1", with primary membership in "group1" and no other memberships and "user2" in "group2".  I created share "share1" and "share2" with owner group and user "admin".  Group1 has read-write privilages in share1 and read-only in share2.   Vice versa for share2.  If user1 creates a file in share1, the ownership is "user1 group1" (his user name and primary group).  Likewise user2 files in share 2 have ownership "user2 group2".  Each user can read, but not overwrite or delete, the other's files in their assigned folder.  All just the way it's supposed to work.

But, my other question is why do you care?  Yes, at the basic Linux level (only accessible if you give the users SSH access), it seems that a unintended group may have access.  But it's not just a Linux machine, it's a NAS.  Do the protocols enabled for the users provide the protection that you are looking for?  If not, perhpas you are looking for protection the NAS is not intended to provide.  The NAS provides share-level access control, not individual file-level protection within a share.

Sandshark wrote: "The NAS provides share-level access control, not individual file-level protection within a share."

That is, what BarkingSpider is wrestling with and where of course OS6 will not meet his expectations.

I recall, that good old Novell Netware was capable of supporting file-level protection when I was administering it in the 90s of the last century.

Would anybody know, whether any vendor of state-of-the art nas is supporting that concept with their firmware?

If all access is via Windows, the file owner can use the Windows security options (right-click, Properties, Security tab) to set file-specific access.  But if any other protocol is being used, there is no guarantee it will be enforced (in fact, I think it typically will not).  But it's not automatic, so you have to remmeber to do it for every file/folder.

---

Retired_Member wrote:

Would anybody know, whether any vendor of state-of-the art nas is supporting that concept with their firmware?

---

Any vendor which is using Windows Server  on the storage system will allow all bells and whistles possible on NTFS and ReFS potentially required by ... Windows. Anybody else does implement subsets only. Or you are going to operate just block based storage on the NAS, and run a fully fledged Windows Server to provide the network access.

If the ReadyNAS allowed you to also share a subfolder of a main share, then BarkingSpider could simply do that (setting different network access for the subfolder).  But it doesn't support that feature.  

In my opinion simply moving the subfolder to it's own primary share is a reasonable workaround, and is the best available option.  Softlinks or perhaps windows shortcuts can be used to preserve access to the subfolder from the main share.

Managing it with file access controls is possible, but IMO there is too much risk that the outside person will either end up with access to files he's not supposed to be able to access, and/or that the person won't be able to access new files that are placed in the folder.

So i seperated out a user and that user is connected to one group

root@WormWood:/data/ztest# id zoro

uid=1030(zoro) gid=510(ostech) groups=510(ostech)

The user zoro creates a file from windows (right click to create new text document):

root@WormWood:/data/ztest# ls -l
total 0
-rwxrwx---+ 1 zoro users 0 Feb 11 15:13 zoro.txt

Why is the group "users" there and not the primary group "ostech"?

Windows 10 advanced security on the file

root@WormWood:/data/ztest# getfacl zoro.txt
# file: zoro.txt
# owner: zoro
# group: users
user::rwx
user:admin:rwx
user:zoro:rwx
group::rwx
group:admin:rwx
group:users:rwx
mask::rwx
other::---

root@WormWood:/data/ztest# getfacl /data/ztest/
# file: data/ztest/
# owner: admin
# group: admin
user::rwx
user:admin:rwx
user:zoro:rwx
group::rwx
group:admin:rwx
mask::rwx
other::---
default:user::rwx
default:user:admin:rwx
default:user:zoro:rwx
default:group::rwx
default:group:admin:rwx
default:mask::rwx
default:other::---

How is the network access set in the share settings?

on the SMB tab, user zoro r/w, nothing else other than default admin, on the file access tab, same. Folder Owner & Folder group checked, only the one user r/w and the default admin, and the  Owner/Group is set to admin.

---

BarkingSpider wrote:

on the SMB tab, user zoro r/w, nothing else other than default admin, on the file access tab, same. Folder Owner & Folder group checked, only the one user r/w and the default admin, and the  Owner/Group is set to admin.

---

Ok.  Can you try creating an account in the user group, and access the NAS shares using that user's credentials?  You shouldn't be able to access any files in the share.

You are correct. No other user can get access this share since there is only ONE user in the share's ACL.  What I'm getting at is why is the group "users" there on the FILES  that are being created and not their primary group.

---

BarkingSpider wrote:

What I'm getting at is why is the group "users" there on the FILES  that are being created and not their primary group.

---

I do understand the question, but wanted to confirm that file access setting wasn't compromising your security.

I agree it is odd the file is showing the users group..

---

StephenB wrote:

---

BarkingSpider wrote:

What I'm getting at is why is the group "users" there on the FILES  that are being created and not their primary group.

---

I do understand the question, but wanted to confirm that file access setting wasn't compromising your security.

 

I agree it is odd the file is showing the users group..

---

This's probably the most discussed question on various NAS vendors communities, being QNAP, Synology, or ReadyNAS. The users group is a default group where all users are members - explicitly or on most platforms impllicitly. Very similar to the "Authenticated Users" or "Domain Users" on an AD.

While QNAP and Synology don't offer it in the UI, ReadyNAS has the option to set a default or primary user group for the group. In my opinion, this does cause more confusion but added value. But then, there is - in my opinion - much more worng on the file protections on ReadyNAS (6.10-Beta1 including) when it comes to folder and files access rights (as effectively in place on the NAS itself).

When creating a new shared folder, remove any default access (inlcuding the non-authenticated guest access) and only allow read+write to SMB for a group alos named engineering, this is the shared folder root holding the data  

root@RN628X:~# getfacl /data/engineering
getfacl: Removing leading '/' from absolute path names
# file: data/engineering
# owner: guest
# group: guest
user::rwx
user:admin:rwx
user:guest:rwx
group::rwx
group:admin:rwx
group:guest:rwx
mask::rwx
other::rwx
default:user::rwx
default:user:admin:rwx
default:user:guest:rwx
default:group::rwx
default:group:admin:rwx
default:group:guest:rwx
default:mask::rwx
default:other::rwx

Completely wrong - the ACLs of the shred folder root do NOT reflect ... anything set in the access rights.

root@RN628X:~# getfacl /data/engineering/test
getfacl: Removing leading '/' from absolute path names
# file: data/engineering/test
# owner: [my_real_username_here]
# group: users
user::rwx
user:admin:rwx
user:guest:rwx
user:[my_real_username_here]:rwx
group::rwx
group:admin:rwx
group:guest:rwx
group:users:rwx
mask::rwx
other::rwx
default:user::rwx
default:user:admin:rwx
default:user:guest:rwx
default:user:[my_real_username_here]:rwx
default:group::rwx
default:group:admin:rwx
default:group:guest:rwx
default:group:users:rwx
default:mask::rwx
default:other::rwx

root@RN628X:~# getfacl /data/engineering/test2/Neues\ Textdokument.txt
getfacl: Removing leading '/' from absolute path names
# file: data/engineering/test2/Neues Textdokument.txt
# owner: [my_real_username_here]
# group: users
user::rwx
user:admin:rwx
user:guest:rwx
user:[my_real_username_here]:rwx
group::rwx
group:admin:rwx
group:guest:rwx
group:users:rwx
mask::rwx
other::rwx

Of course, we can go and adjust - to some extent - the File Access for the shared folder:



Still, there are several more than strange file access items reamining, inlcuding the ReadyCloud cloud user(s):

Granted, this does not break the access to the shared folder using the (only!) defined access by SMB - but it's simply wrong from the audit prospective. Reported this many times already during the ReadyNAS OS 6 Beta - still, file and folder ownership as well as ACL do not properly relefct the effectively intended access rights. 

And you complain "just" about the default users group? That's just the peak of the ice berg.

In my opinion, this is wrong bottom up and does prohibit any serious (IT audited) business use of ReadyNAS.

Wanted to add some tags mentioning some key people like OOM-9 and wonder what they reply here.