Lab 3 - Kerberized NFS4

The third lab teaches how to get NFS4 working with Kerberos.

Before you start remove the file /etc/krb5.keytab from the previous lab. The instructions below only work with a user keytab as system keytab.

Configure NFS4 Client

Follow the instructions here to configure your test system.

When done run the following command to mount the test share prepared for this lab:

# mount -t nfs -o nfsvers=4,minorversion=0,sec=krb5p inf.nas.ethz.ch:/fs1201/infk_isg_test /mnt

Log in to your test system with your ETH user name and make sure that you have a valid ticket (run klist). Now run the following commands:

$ cd /mnt
$ touch $USER
$ ls -la $USER

You should see an empty file with your user name but the wrong owner and group (nobody or 4294967294).

The file server used is the ITS NAS which is configured to only know users and groups in the Active Directory.

Questions

Why does the file apparently belong to nobody? Answer
NFS4 uses names instead of numeric IDs to convey ownership information. Those names are in a format like {user or group}@D.ETHZ.CH@ETHZ.CH and your test system does not yet know how to map these to local users.

Configure the Identity Mapper

Follow the instructions here to configure the identity mapper.

Run the following command to flush the internal name mapping cache:

# nfsidmap -c

Now re-run the list command:

$ ls -la $USER

The file should now belong to you but may still have nobody or 4294967294 as group. Run the following command to change it to the AD group users:

$ chgrp users $USER
$ ls -la $USER

The file has the correct permissions now. Run

$ ls -la

You see the other files of the workshop participants and they all seem to belong to nobody.

$ ls -la /infnas/infk_isg_test

There you see the same files but with the correct ownership.

Questions

What group does the file actually belong now? Answer
The group Domain Users. In the file /etc/idmapd.conf there is a static mapping for the local group users to domain users on the remote server.
What would be needed that you see the correct ownership of all files on your test system?Answer
Your test system would have to be configured to use the AD or our LDAP tree for name services. optimus.inf.ethz.ch is configured this way, that is why there you see all names.

ACLs

ACLs are used to grant more granular access rights for files and directories. A typical scenario is to have a directory with data and give rights to a groups of users. To ensure consistency the rights should be inherited to new files and directories too.

Do all the steps below on optimus.inf.ethz.ch. Start by removing the file with your login as name and replace it with a directory that only you can access:

$ rm /infnas/infk_isg_test/$USER
$ mkdir /infnas/infk_isg_test/$USER
$ chmod 700 /infnas/infk_isg_test/$USER

Check the NFS4 ACL with the nfs4_getfacl command:

$ nfs4_getfacl /infnas/infk_isg_test/$USER

The output should be this:

A:fdO:OWNER@:rwaDdxtTnNcCoy
A:fdO:GROUP@:tncy
A:fdO:EVERYONE@:tncy

These ACLs are actually inherited from /infnas/infk_isg_test. Run the following command to look at the respective ACLs:

$ nfs4_getfacl /infnas/infk_isg_test

Questions

What could OWNER@, GROUP@, EVERYONE@ mean? Answer
These ACLs are for the current user and group that owns a file or directory, and all other users. They are partially redundant to the basic file mode but allow more granular rights.
Why are there two rules per OWNER@, GROUP@, EVERYONE@? Answer
One ACL is for the actual access to /infnas/infk_isg_test and one is for the inheritance, i.e., the ACL that a newly created file or directory gets.

Now lets grant read access to the Domain Users group to your directory, including inheritance:

$ nfs4_setfacl -a 'A:dg:D\domain users@ETHZ.CH:xrtncy' /infnas/infk_isg_test/$USER
$ nfs4_setfacl -a 'A:fg:D\domain users@ETHZ.CH:rtncy' /infnas/infk_isg_test/$USER

Question

What is the difference between these two rules? Answer
The rtncy stands for read access alone and is sufficient for files. The xrtncy also includes execute right which is needed for directories.

Now, create a file in the directory and verify its ACLs:

$ echo $USER >/infnas/infk_isg_test/$USER/owner
$ nfs4_getfacl /infnas/infk_isg_test/$USER/owner

You will see that the new file has the file ACL inherited. Now do the same for a directory:

$ mkdir /infnas/infk_isg_test/$USER/more
$ nfs4_getfacl /infnas/infk_isg_test/$USER/more

This time the directory has inherited the directory ACL including the x.

Wait until other workshop participants have also come this far and check if you can read the file owner in their directory:

$ cat /infnas/infk_isg_test/*/owner