Permission issues on ZFS dataset

V

vieron

Hi everyone,


I created a new ZFS dataset
Code: 
root@vieron:~ # zfs create zroot/playground
root@vieron:~ # ls -ld /zroot/playground/
drwxr-xr-x  2 root  wheel  2 Mar 17 12:40 /zroot/playground/


and assigned read and write permissions to the "labgroup" group
Code: 
root@vieron:~ # chmod 775 /zroot/playground/
root@vieron:~ # chown :labgroup /zroot/playground/
root@vieron:~ # ls -ld /zroot/playground/
drwxrwxr-x  3 root  labgroup  5 Mar 17 12:41 /zroot/playground/
root@vieron:~ #

I then switched to user "lab1" that is part of "labgroup" and created a test file and directory

Code: 
root@vieron:~ # id lab1
uid=1001(lab1) gid=1001(lab1) groups=1001(lab1),0(wheel),1004(labgroup)
root@vieron:~ # su - lab1
lab1@vieron:~ $ cd /zroot/playground/
lab1@vieron:/zroot/playground $ touch test
lab1@vieron:/zroot/playground $ mkdir testdir
lab1@vieron /zroot/playground % ls
test    testdir
lab1@vieron /zroot/playground %

I then tried changing the permissions of the mounted dataset
Code: 
root@vieron:~ # chmod g+s /zroot/playground/
root@vieron:~ # ls -ld /zroot/playground/
drwxrwsr-x  3 root  labgroup  5 Mar 17 12:41 /zroot/playground/
root@vieron:~ #

and all of a sudden the permissions I first had didn't work anymore
Code: 
lab1@vieron /zroot/playground % touch newfile
touch: newfile: Permission denied
lab1@vieron /zroot/playground % mkdir newdir
mkdir: newdir: Permission denied
lab1@vieron /zroot/playground %


I even tried resetting the permissions to how they were before but still couldn't write to the directory
Code: 
root@vieron:~ # chmod g-s /zroot/playground/
root@vieron:~ # ls -ld /zroot/playground/
drwxrwxr-x  3 root  labgroup  5 Mar 17 12:41 /zroot/playground/
root@vieron:~ #
lab1@vieron /zroot/playground % touch newfile
touch: newfile: Permission denied
lab1@vieron /zroot/playground % mkdir newdir
mkdir: newdir: Permission denied
lab1@vieron /zroot/playground %


This sort of problem seems kind of randomic in the sense that if I destroy and recreate the same dataset it might not work and if I recreate it once again it might work.
Code: 
root@vieron:~ # zfs destroy zroot/playground
root@vieron:~ # zfs create zroot/playground
root@vieron:~ # chmod 775 /zroot/playground/
root@vieron:~ # chown :labgroup /zroot/playground/
root@vieron:~ #
lab1@vieron ~ % cd /zroot/playground
lab1@vieron /zroot/playground % touch newfile
touch: newfile: Permission denied
lab1@vieron /zroot/playground % mkdir newdir
mkdir: newdir: Permission denied
lab1@vieron /zroot/playground %


Is there something I am missing or do not understand regarding ZFS datasets and permissions or permissions in general?

I have just noticed that it seems I have the same kind of issue on other datasets
Code: 
lab1@vieron /testdir % ls -ld .
drwxrwxr-x  2 root  labgroup  2 Mar 17 14:20 .
lab1@vieron /testdir % ls
lab1@vieron /testdir % touch test
touch: test: Permission denied
lab1@vieron /testdir %
lab1@vieron /testdir % id lab1
uid=1001(lab1) gid=1001(lab1) groups=1001(lab1),0(wheel),1004(labgroup)
lab1@vieron /testdir %
 
Thanks for your reply yuripv79 . My worry isn't really "just" sharing files but that my ZFS based system isn't "stable". I'm pretty sure I must be missing something but I don't know what that could be. If I use another operating system like Linux and launch the same commands as above things work out as I expect. So I'm guessing that I'm not doing something correctly as should be done on FreeBSD/ZFS.
 
Another thing I would like to mention which I find strange and might have something to do with the problem I am encountering is that if I launch the following command I don't see the "labgroup" group
Code: 
lab1@vieron /zroot/playground % id
uid=1001(lab1) gid=1001(lab1) groups=1001(lab1),0(wheel)
lab1@vieron /zroot/playground %

meanwhile if I launch the same command with the user "lab1" as argument I see the supplementary group "labgroup". This might just be normal behaviour but thought that it might be useful to point it out
Code: 
lab1@vieron /zroot/playground % id lab1
uid=1001(lab1) gid=1001(lab1) groups=1001(lab1),0(wheel),1004(labgroup)
lab1@vieron /zroot/playground %
 
I think the user yuripv79 is right.

setfacl(1)

For example this command assign all permissions to user test can do the same with groups:

setfacl -m u:test:full_set::allow dir
Click to expand...

Other than that I think zfs has two properties called aclinherit and aclmode, but I don't think you have to modify them for that purpose.
 
vieron said:
My worry isn't really "just" sharing files but that my ZFS based system isn't "stable".
Click to expand...
Please show the output from mount for that dataset, specifically if nosuid is specified in the options (or if the setuid property is set to off for it).
 
Hi freejlr and yuripv79 thank you guys for your replies.

First of all I haven't been experiencing the "Permission denied" issue since I started this thread. Secondly I was quite confused with sgid on FreeBSD and just found out here that SYSV systems and BSD derived systems behave differently when it comes to using sgid on directories: on BSD systems the sgid behaviour for directories seems to be the default without even having to apply chmod g+s.

Regarding the NFS ACLs I have started looking in to them and as you guys have mentioned they are probably my best bet for configuring permissions in a bit more of an advanced way. I initially thought that NFS ACLs were only meant for applying permissions on NFS exports and thought they were not meant for locally shared files and directories but am now guessing that that is maybe not the case. The only "issue" I have noticed though is that, as stated in setfacl(1)(), NFSv4 doesn't support default ACLs on directories which kind of limits the way I would like to use them (at least on ZFS).

yuripv79 these are the options I see on the newly created ZFS dataset
Code: 
root@vieron:~ # mount | grep zroot/playground
zroot/playground on /zroot/playground (zfs, local, noatime, nfsv4acls)
root@vieron:~ #
and here I can see that the setuid property is on by default
Code: 
root@vieron:~ # zfs get setuid zroot/playground
NAME              PROPERTY  VALUE   SOURCE
zroot/playground  setuid    on      default
root@vieron:~ #
 
vieron said:
Another thing I would like to mention which I find strange and might have something to do with the problem I am encountering is that if I launch the following command I don't see the "labgroup" group
Code: 
lab1@vieron /zroot/playground % id
uid=1001(lab1) gid=1001(lab1) groups=1001(lab1),0(wheel)
lab1@vieron /zroot/playground %

meanwhile if I launch the same command with the user "lab1" as argument I see the supplementary group "labgroup". This might just be normal behaviour but thought that it might be useful to point it out
Code: 
lab1@vieron /zroot/playground % id lab1
uid=1001(lab1) gid=1001(lab1) groups=1001(lab1),0(wheel),1004(labgroup)
lab1@vieron /zroot/playground %
Click to expand...
If you modified /etc/group when the current session was already started then it may not see the change. Log out and log in.
 
Hi Andriy,

after reading your reply I investigated further and can confirm that something regarding the group not showing up correctly with the id command must have been the issue. I have tried recreating a few groups and this time id always reflects the new groups correctly

Code: 
root@vieron:~ # pw groupadd -n testgroup -M lab1
root@vieron:~ # su - lab1
lab1@vieron:~ $ id
uid=1001(lab1) gid=1001(lab1) groups=1001(lab1),0(wheel),1004(testgroup)
lab1@vieron:~ $ id lab1
uid=1001(lab1) gid=1001(lab1) groups=1001(lab1),0(wheel),1004(testgroup)
lab1@vieron:~ $

So thank you very much Andriy that definitely reassures me since I know the issue had nothing to do with ZFS or permissions in themselves but with "non refreshed" user group information which is much less serious in my opinion. It is possible that I had initially messed something up during the initial group creation since I haven't issued pw commands in a while.

At this point I'll mark the thread as resolved (if I find how to do it 😅). Thank you!
 
You must log in or register to reply here.
Back
Top