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

littlesandra88

littlesandra88

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 ?
 
@littlesandra88

It is also a LDAP client.
Click to expand...

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
 
@Sebulon

Don´t you really mean LDAP server? Or is the file server configured for another LDAP, outside of the server?
Click to expand...

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?
Click to expand...

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

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

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

Code: 
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

Code: 
# 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.
Click to expand...

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

Code: 
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 =)
 
@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
 
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.
 
@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.
Click to expand...

Ok, this is very interesting!

When I on the Linux client don't have

Code: 
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
Code: 
# 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
Code: 
# 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

Code: 
[General]
Domain = example.com
...

/etc/rc.conf on ZFS server
Code: 
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"
 
@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:
Code: 
[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
 
@Sebulon
But this is just brainstorming, I´m not sure if my assumptions are correct.
Click to expand...

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

Code: 
# 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?
 
@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.
 
You must log in or register to reply here.
Back
Top