Use of -anon option in /etc/exports

[Bruno Bossier]

Something is not clear to me about the use of the -anon option in /etc/exports.

My understanding is that if a user of a NFS client tries to write something into a NFS mounted filesystem and that user is unknown on the NFS server (nor username, nor uid), the NFS server will use the uid specified with the -anon option specified in /etc/exports on the NFS server so that it could write anyway into that filesystem (which has the ownership set to the same user used with the -anon option).

Can someone explain ?

Thanks,
Bruno

[Pete Randall]

Bruno,

From the exports man page:

"anon=uid If a request comes from an unknown user, use uid as the
effective user ID. Note: Root users (uid 0) are always
considered ``unknown'' by the NFS server unless they
are included in the root option below.

The default value for this option is -2. Setting anon
to -1 disables anonymous access."

I would say you understand it pretty well.


Pete

[Bruno Bossier]

Well, that is not the case. I created a dummy user on the NFS client (username and uid unknown on the NFS server). Then I tried to write something into the NFS mounted filesystem on the client, but it fails. I would expect that it works as the NFS server does not known my username and uid and thus use the uid specified with the -anon option so that I could write anyway in the NFS mounted filesystem.

What is wrong ? Here some data :

NFS server :
------------
# cat /etc/exports
/bruno -anon=11385

# grep 11385 /etc/passwd
bruno:*:11385:1:BRUNO:/home/bruno:/usr/bin/sh

# ll -d /bruno
drwxr-xr-x 3 bruno users 96 Apr 17 16:23 /bruno

# bdf /bruno
Filesystem kbytes used avail %used Mounted on
/dev/vg_apps/lv_bruno
8192 1109 6648 14% /bruno

# grep ^test /etc/passwd

# grep 11589 /etc/passwd


NFS client :
------------
# grep ^test /etc/passwd
test:*:11589:1::/home/test:/usr/bin/sh

# ll -d /bruno
drwxr-xr-x 3 11385 users 96 Apr 17 16:23 /bruno

# bdf /bruno
Filesystem kbytes used avail %used Mounted on
server:/bruno 8192 1112 6648 14% /bruno

[test@client:/home/test]
$ touch bb /bruno/bb
touch: /bruno/bb cannot create

[Bruno Bossier]

Just as an additional note to my previous mail is that the version of HP-UX is 11.00. This is important to say as in HP-UX 10.20 it seems that only the root user is considered unknown whereas other users are not even if they do not exist in /etc/passwd on the NFS server.

Is that still the case on HP-UX 11.00 or has that changed ?

[Todd Whitcher]

Hello Bruno,

What happens when you allow Unix Write Permissions to that exported directory for non-owners, only the owner of your exported file has write permissions.

Permissions are controlled first by the HPUX File Permissions on the Server, NFS Permissions set in /etc/exports and then the underlying mount point on the nfs client. The NFS permission wont overwrite the permissions set on the NFS servers local file.

[Shannon Petry]

Bruno,

This will be a bit lengthy, but I hope to show exactly how this works.

The -anon option allows you to set the UID when it is unknown to the NFS server. The default UID is nobody(65534).

Lets assume your client has a passwd entry
johndoe:x:2233:2233::/nfsserver/johndoe:/bin/sh

Lets assume that the NFS server has a default passwd file. The export is given -anon=0. Now when a client connection is made, the UID of the person accessing.

When johndoe tries to access the server for any action, the server asks the client for your credentials. The client would pass to the server UID=2233. The server, would see that this is an unknown UID on it's system. The default permissions would then be set to 0(root) allowing the access. Part of file creation is to set permissions and ownership. The file should then be set to the users umask, and the UID owning the file would be set to 2233.

The default permissions on unknown users would deny them access to the exported file system, and dis-allow writes. Like so..

johndoe requests to write a file. server requests credentials from client. client reports UID=2233. Server sees no such ID, so maps to 65534. This would then deny them access to the file system. (same action as -anon=65534).

Most of the time, then -anon option is used in conjunction with ACL's allowing specific hosts access to the file system, and -anon set to 0. This is insecure, but would ensure that users could access data and modify data.

If you made a default UID on a system, which is your NFS ID. I.E.
nfsid:x:2233:2233::/export:/bin/true
then exported with a -anon=2233, you would get some degree of success. But... here is where most problems occur.

Another user janedoe(UID=2244) connects to the system.
janedoe tries to create a file. The system polls the client for credentials, and receives UID=2244. Since it does not exist, it maps the UID to 2233(per our -anon=2233) granting access.

Now, jane doe makes her file. As previously mentioned, part of file creation is to set permissions and ownership. When janedoe makes her file, the ownership is changed to 2244. When janedoe tries to connect and modify this file, the UID is mapped back to 2233, dis-allowing the access to write the file.

Now, there are ways to work through this. I.E. global umask of 0000, script on the server to change ownership of all files/dirs to 2233, etc... But it's definately not easy, and requires a bit of maintenance to achieve good results.

I hope this helps.

Sincerely,
Shannon