NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Shares user and and group permissions
Hi, 4 years after this thread... https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/User-and-group-broken-permissions/td-p/1107451/page/3 I am migrating to FreeNAS and turni...
Sandshark wrote:
chopin70 wrote:
nteresting
However, that is really a very bad fix you suggested
I agree. That is a good way for a home network, where SMB is typically the only protocol in use, so the admin doesn't get lost in the sea of both network and file permissions, but it is not suitable for a business environment.
I do agree that using Network Access alone doesn't work if you give a user with restricted access to files the ability to log into the NAS with SSH. But in my opinion that is bad practice anyway - only admins should have SSH access to the NAS.
I don't see what the other protocols have to do with it, since you need to set up network access for all of them properly anyway. If you try to use file permissions alone, then anyone with write access to the folder can change the permissions - so they can elevate the permissions of others. One way or another you need to set the network access for all protocols properly if you want to ensure that the restricted access sticks. And in most cases (home or business) that is enough.
It doesn't work that way.
We should be able to set group ACLS from windows once the group permissions are specified in GUI. Currently even this basic acls part is broke.
Once ACLS permissions are set at group level, they would properly apply tu users and they will manage both smb AND unix accesses.
I have a sync_agent user to sync mobile phones to nas and an rsync user to accept pull requests for backups through ssh and not the insecure modules. So it needs a shell access with ssh cert and no pass. I also have a few users needing a shell access.
I properly secured a non root ssh access for the rsync user using sudo and a locked authorized_keys command pointing to a shell script.
In anycase, the way acls are implemented is buggy. And the way you suggest leaves a hole if a user needs shell access. The NAS is not sold as "Home only", so no excuses to leave it unfinished by Netgear. Hope it gets fixed.
Any Netgear tech we can ping ?
We should be able to set group ACLS from windows once the group permissions are specified in GUI. Currently even this basic acls part is broke.
Once ACLS permissions are set at group level, they would properly apply tu users and they will manage both smb AND unix accesses.
I have a sync_agent user to sync mobile phones to nas and an rsync user to accept pull requests for backups through ssh and not the insecure modules. So it needs a shell access with ssh cert and no pass. I also have a few users needing a shell access.
I properly secured a non root ssh access for the rsync user using sudo and a locked authorized_keys command pointing to a shell script.
In anycase, the way acls are implemented is buggy. And the way you suggest leaves a hole if a user needs shell access. The NAS is not sold as "Home only", so no excuses to leave it unfinished by Netgear. Hope it gets fixed.
Any Netgear tech we can ping ?
FWIW, when I set file permissions so that the group smb_enfants_ro is read-only in the GUI, I also end up with read-only access for enfants2. I did not set any permissions for enfants. I confirmed first that with network access also set with the group having only read access - and then confirmed it again with network access giving everyone rw access.
The linux ACL for the each file in the folder looks like this:
root@NAS:/data/enfants2# getfacl * # file: FileAccess.png # owner: admin # group: admin user::rwx user:admin:rwx user:guest:rwx group::rwx group:admin:rwx group:guest:rwx group:smb_enfants_ro:r-x mask::rwx other::---
This file was copied into the share from windows previously with admin credentials.
The linux ACL for the share itself looks like this:
root@NAS:/data/enfants2# getfacl . # file: . # owner: guest # group: guest user::rwx user:admin:rwx user:guest:rwx group::rwx group:admin:rwx group:guest:rwx group:smb_enfants_ro:r-x mask::rwx other::--- default:user::rwx default:user:admin:rwx default:user:guest:rwx default:group::rwx default:group:admin:rwx default:group:guest:rwx default:group:smb_enfants_ro:r-x default:mask::rwx default:other::---
The share is owned by guest/guest, and folder group and folder owner both are set to rw access.
Note I did not attempt to apply file permissions from Windows - I set them for the share using the web ui.
chopin70 wrote:
Any Netgear tech we can ping ?Wired,
In my case and above test, the File Permissions applied only at group level in the GUI did not propagate to the users in linux shell mode.
Furthermore, changing File Permissions in GUI did not propagate them to the ACLS. It is rather the "Network TAB" in my case that did propagate the ACLS permissions to Windows 10 ACLS.
As shown in my above screeshots, the user teddy still got r/w permissions and could delete tommy's owned folder at the root of the freshly created office share which is just amazing and should never happen as far as I know.
Anyway, maybe there is an inconsitent bug in GUI that causes this ?
My advise is to ensure all permissions are properly propagated to windows 10 ACLS. Once verified, to only apply them from windows 10 and to verify that they properly apply to the shell access, either you are using it or not for security reasons.
It might be worth posting the linux ACL (which I am not seeing in your images). The acl in my previous post was examined with network access set to everyone rw, and file permissions restricting access to the group to ro. AFAICT that did propagate correctly.
Testing with ssh:
enfants@NAS:~$ cd /data/enfants2 enfants@NAS:/data/enfants2$ ls -al total 100 drwxrwx---+ 1 guest guest 82 Nov 15 19:43 . drwxr-xr-x 1 root root 530 Nov 12 19:20 .. -rwxrwx---+ 1 admin admin 36981 Nov 12 19:12 FileAccess.png -rwxrwx---+ 1 admin admin 27040 Nov 12 19:11 NetworkAccess.png enfants@NAS:/data/enfants2$ rm NetworkAccess.png rm: remove write-protected regular file 'NetworkAccess.png'? y rm: cannot remove 'NetworkAccess.png': Permission denied
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
