# Possible to get LDAP group permissions to ZFS ACL's?



## littlesandra88 (Nov 29, 2012)

Hi =)

My setup: I have a working FreeBSD 9 with a ZFS file system shared over NFSv4. It is also a LDAP client. In the LDAP server have I a group called "project1" which have "user1,user2".

Question: Is it possible that everyone that is in the project1 group gets read/write access to /tank/project1 which is a ZFS file system shared with NFSv4 ?


----------



## Sebulon (Nov 30, 2012)

@littlesandra88



> It is also a LDAP client.



DonÂ´t you really mean LDAP server? Or is the file server configured for another LDAP, outside of the server? And are user1- and 2Â´s workstations also set up against that LDAP and "know" about this group?

Well, in any case itÂ´s just a matter of setting the ACL. Something along the lines of:
`# setfacl -m group:project1:rwxpDdaARWcCos:fd----:allow /tank/project1`

/Sebulon


----------



## mamalos (Nov 30, 2012)

...as long as your nsswitch mechanism is properly configured, on the machine the filesystem is mounted on, to resolve the groups you're mentioning, through LDAP.


----------



## littlesandra88 (Dec 3, 2012)

@Sebulon



> DonÂ´t you really mean LDAP server? Or is the file server configured for another LDAP, outside of the server?



A bit of misleading information from my part I see =) The LDAP server, which turned out to be a NIS, is a separate server, where the FreeBSD is a client of that.



> And are user1- and 2Â´s workstations also set up against that LDAP and "know" about this group?



user1 and user2 won't login directly from their workstatons, but rather through other servers first, where some of these servers have NIS and others have user1 and user2 as local users.

After having added nis to /etc/nsswitch.conf as mamalos mentioned and executed your setfacl commands, everyone can access the share.

From a CentOS box without NIS I mount it with


```
mount -v -t nfs4 test-freebsd9:tank/project1 /mnt/project1/
```

and all local users can cd into the directory, but not do anything.


```
linux# getfacl /mnt/project1/fff 
getfacl: Removing leading '/' from absolute path names
# file: mnt/project1/fff
# owner: root
# group: wheel
user::rw-
group::r--
other::r--
```

On the FreeBSD I have


```
# zfs get all|grep share  
tank           sharenfs              off                    default
tank           sharesmb              off                    default
tank/project1  sharenfs              -maproot=0:0           local
tank/project1  sharesmb              off                    default
```

Are there some permissions I have/haven't set?


@mamalos



> ...as long as your nsswitch mechanism is properly configured, on the machine the filesystem is mounted on, to resolve the groups you're mentioning, through LDAP.



After adding nis to /etc/nsswitch.conf is then looks like


```
group: compat nis
group_compat: nis
hosts: files dns
networks: files
passwd: compat
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files
```

and the setfacl commands goes through =)


----------



## Sebulon (Dec 4, 2012)

@littlesandra88

Strangest. LDAP. Ever

Make sure that both file server and the servers that users are connecting to are properly configured and "know" about these groups and itÂ´s users. Either towards the NIS or local accounts with the same U/G-ID.

From the "zfs get" command, it looks like you configured ZFS to export that share everywhere. Kind of like creating an SMB share with "EVERYONE - Full Control", so that everyone is able to map/mount the share, but not everyone is able to do anything inside it.

On the ZFS server, what does this command give:
`# getfacl /tank/project1`

And also on one of the servers that have this share mounted:
`# getfacl /mnt/project1`

/Sebulon


----------



## SirDice (Dec 4, 2012)

You might want to tell your boss to dump NIS and go for LDAP. NIS is rather insecure, it's fairly easy to get a list of all users including their passwords. With rainbowtables they are very simple to crack these days.


----------



## littlesandra88 (Dec 4, 2012)

@SirDice

Yes, I don't like NIS either, and it is on my TODO to migrate it to LDAP =)

@Sebulon


> Make sure that both file server and the servers that users are connecting to are properly configured and "know" about these groups and itÂ´s users. Either towards the NIS or local accounts with the same U/G-ID.



Ok, this is very interesting!

When I on the Linux client don't have


```
project1:x:1446:sandra
```

in /etc/group I get a Permission Denied. Adding it, allows the sandra user to write. This I don't understand.

I would have expected (and hoped) that the Linux box without NIS client didn't had to know about the groups. I.e. the group concept were only used on the FreeBSD box when using setfacl.

Question:
Why does the Linux box need to know about the members of "project1"? Can it be avoided, so the Linux box only knows the correct UID's?


Info:

ZFS server

```
# getfacl /tank/project1
# file: /tank/project1
# owner: root
# group: wheel
  group:project1:rwxpDdaARWcCos:fd----:allow
          owner@:rwxp--aARWcCos:------:allow
          group@:r-x---a-R-c--s:------:allow
       everyone@:r-x---a-R-c--s:------:allow
#
```

Linux box without NIS

```
# getfacl /mnt/project1
getfacl: Removing leading '/' from absolute path names
# file: mnt/project1
# owner: root
# group: wheel
user::rwx
group::r-x
other::r-x
```

Changed Domain in /etc/idmap.conf on Linux box


```
[General]
Domain = example.com
...
```

/etc/rc.conf on ZFS server

```
zfs_enable="YES"
rpcbind_enable="YES"

nfs_server_enable="YES"
nfs_server_flags="-u -t -n 1"
nfsv4_server_enable="YES"
nfsuserd_enable="YES"
nfsuserd_flags="-domain example.com"

mountd_flags="-r"
mountd_enable="YES"
portmap_enable="YES"

rpc_lockd_enable="YES"
rpc_statd_enable="YES"

nisdomainname="example.com"
nis_client_enable="YES"
```


----------



## Sebulon (Dec 5, 2012)

@littlesandra88

The ACL is set for group, not user. If you wanted Linux boxes only to know about the users, youÂ´d have to configure ACLÂ´s based on that- adding user for user allowed to modify that content.

The fileserver only has exported the filesystem and have ACLÂ´s set on it. It doesnÂ´t know/care if you are part of that group or not, thatÂ´s up to your workstation to decide.

After thinking about this a little more, IÂ´m not even sure that your file server has to know about those users and groups at all. Since youÂ´re exporting the filesystem as root, you should be able to set any ACLÂ´s on any client regardless of what the file server knows about. Say you have defined a group called "Foobar" with GID 1337 on your two clients. When you have mounted the ZFS export on one of your clients, as root you should be able to:
`# setfacl -m group:Foobar:rwxpDdaARWcCos:fd----:allow /mnt/project1`

And on the fileserver that ACL should get set but just look like:

```
[CMD="#"]getfacl /tank/project1[/CMD]
...
group:1337:rwxpDdaARWcCos:fd----:allow
...
```

And then itÂ´s totally up to both your clients if any of your users get permission or not.

But this is just brainstorming, IÂ´m not sure if my assumptions are correct.

/Sebulon


----------



## littlesandra88 (Dec 5, 2012)

@Sebulon


> But this is just brainstorming, IÂ´m not sure if my assumptions are correct.



That would be interesting to figure out, so I have done this on my Linux box without NIS


```
# groupadd -g1337 Foobar
# mount -v -t nfs4 -o remount,acl test-freebsd9:tank/project1 /mnt/project1/
mount.nfs4: timeout set for Wed Dec  5 12:15:08 2012
mount.nfs4: trying text-based options 'acl,addr=10.10.10.231,clientaddr=10.10.10.83'
# setfacl -m group:Foobar:rwxpDdaARWcCos:fd----:allow /mnt/project1
setfacl: Option -m: Invalid argument near character 17
```

What would you say could be concluded from this?


----------



## littlesandra88 (Dec 5, 2012)

@Sebulon

I have now gotten ACL's for users to work. I needed to run

`# pwd_mkdb -p /etc/master.passwd`

to get /etc/passwd updated and its db files.

I think you are right, that it is the nfs client that preforms the ACL check and not the ZFS server, as I mount the NFS share on the client without any user authentication

`# mount -v -t nfs4 -o remount,acl test-freebsd9:tank/project1 /mnt/project1/`

So it has to the nfs client that performs the access control, as I see it.


----------

