When using NFSv3 UID & GID in RPC headers from client changes unexpectedly
up vote
0
down vote
favorite
I have been using NFS for several years and accepted its limitations in terms of security and lack of authentication etc. This was fine as I'm only using it in a small and secure network environment. Recently I upgraded my server to 18.04 LTS and decided to take a closer look at NFS with the aim of moving to using NFSv4. This has proved to be a headache for several reason, I'm running Ubuntu, Macs and Windows clients, so I was expecting a mixture of NFSv3 and NFSv4, but it proved to be a lot more difficult than I expected.
I have now spent days carefully trying to understand the subtleties of how the client and server exchange works on the wire. I have hit an issue that I just can not google the answer too. Maybe someone else can explain.
I have an Ubuntu server (18.04) running both NFSv3&4. I have configured an export and I share it out with: (rw,insecure,subtree_check,no_root_squash). I choose specifically not to use root squashing as I wanted to observe the exact behaviour when I attempt to mount from a client.
When I logged in as root on the client I issue the mount command:
mount -t nfs -o vers=3 mx:/mnt/shared_sun_NAS/Videos /mnt/Videos
sure enough it mounts....
When I look at the exchange on the wire I see the expected exchanges:
- Portmap - GETPORT Call NFS TCP
- Portmap - GETPORT Reply Port 2049
- NFS - NULL Call
- NFS - NULL Reply success
- Portmap - GETPORT Call MOUNT UDP
- Portmap - GETPORT Reply Port 65500 (I choose this port on the server)
- MOUNT - NULL Call
- MOUNT - NULL Reply success
- MOUNT - NULL Call
- MOUNT - NULL Reply success
- MOUNT - MNT Call /mnt/shared_sun_NAS/Videos
- MOUNT - MNT Reply success
- Portmap - GETPORT NFS TCP
- Portmap - GETPORT Reply Port 2049
- NFS - NULL Call
- NFS - NULL Reply success
- NFS - FSINFO Call FH:xxxx
- NFS - FSINFO Reply success
- NFS - PATHCONF Call FH:xxxx
- NFS - PATHCONF Reply success
- NFS - GETATTR Call FH:xxxx
- NFS - GETATTR Reply success: Dir mode 3770 uid:0 gid:5000 (exactly as on the server)
- NFS - NFSACL Call
- NFS - NFSACL Reply success
- NFS - FSINFO Call FH:xxxx
- NFS - FSINFO Reply success
- NFS - GETATTR Call FH:xxxx
- NFS - GETATTR Reply success: Dir mode 3770 uid:0 gid:5000
- NFS - ACCESS Call DH: xxxx [Check: RD LU MD XT DL]
- NFS - ACCESS Reply success [Allowed: RD LU MD XT DL]
Here I will stop and ask my question:
In each and every frame from 1-28 the RPC header shows:
Machine Name: Laplace
UID: 0
GID: 0
Aux GIDs [0, 5000] just exactly as my root user on the client.
Then as soon as the client moves to ACCESS commands RPC header changes as below:
Machine Name: Laplace
UID: 1000
GID: 1000
Aux GIDs [4...... 5000] just exactly as my user account on the client.
Why does this happen?
The mount command is running as root, I am mounting to a mount point owned by root. The server is serving a directory owned by root. I have no mapping configured anywhere on the client or the server. Why does this ACCESS command get issued as my user account and not as root.
If I change the mount command to NFSv4, these access requests are issued as UID: 0 and GID:0 (as expected. Root!)
What makes the client switch like this? It seems I have no control over this.
Any info help much appreciated.
nfs rpc
asked Nov 12 at 18:36
Aidan Walton
11
add a comment |
up vote
0
down vote
favorite
I have been using NFS for several years and accepted its limitations in terms of security and lack of authentication etc. This was fine as I'm only using it in a small and secure network environment. Recently I upgraded my server to 18.04 LTS and decided to take a closer look at NFS with the aim of moving to using NFSv4. This has proved to be a headache for several reason, I'm running Ubuntu, Macs and Windows clients, so I was expecting a mixture of NFSv3 and NFSv4, but it proved to be a lot more difficult than I expected.
I have now spent days carefully trying to understand the subtleties of how the client and server exchange works on the wire. I have hit an issue that I just can not google the answer too. Maybe someone else can explain.
I have an Ubuntu server (18.04) running both NFSv3&4. I have configured an export and I share it out with: (rw,insecure,subtree_check,no_root_squash). I choose specifically not to use root squashing as I wanted to observe the exact behaviour when I attempt to mount from a client.
When I logged in as root on the client I issue the mount command:
mount -t nfs -o vers=3 mx:/mnt/shared_sun_NAS/Videos /mnt/Videos
sure enough it mounts....
When I look at the exchange on the wire I see the expected exchanges:
- Portmap - GETPORT Call NFS TCP
- Portmap - GETPORT Reply Port 2049
- NFS - NULL Call
- NFS - NULL Reply success
- Portmap - GETPORT Call MOUNT UDP
- Portmap - GETPORT Reply Port 65500 (I choose this port on the server)
- MOUNT - NULL Call
- MOUNT - NULL Reply success
- MOUNT - NULL Call
- MOUNT - NULL Reply success
- MOUNT - MNT Call /mnt/shared_sun_NAS/Videos
- MOUNT - MNT Reply success
- Portmap - GETPORT NFS TCP
- Portmap - GETPORT Reply Port 2049
- NFS - NULL Call
- NFS - NULL Reply success
- NFS - FSINFO Call FH:xxxx
- NFS - FSINFO Reply success
- NFS - PATHCONF Call FH:xxxx
- NFS - PATHCONF Reply success
- NFS - GETATTR Call FH:xxxx
- NFS - GETATTR Reply success: Dir mode 3770 uid:0 gid:5000 (exactly as on the server)
- NFS - NFSACL Call
- NFS - NFSACL Reply success
- NFS - FSINFO Call FH:xxxx
- NFS - FSINFO Reply success
- NFS - GETATTR Call FH:xxxx
- NFS - GETATTR Reply success: Dir mode 3770 uid:0 gid:5000
- NFS - ACCESS Call DH: xxxx [Check: RD LU MD XT DL]
- NFS - ACCESS Reply success [Allowed: RD LU MD XT DL]
Here I will stop and ask my question:
In each and every frame from 1-28 the RPC header shows:
Machine Name: Laplace
UID: 0
GID: 0
Aux GIDs [0, 5000] just exactly as my root user on the client.
Then as soon as the client moves to ACCESS commands RPC header changes as below:
Machine Name: Laplace
UID: 1000
GID: 1000
Aux GIDs [4...... 5000] just exactly as my user account on the client.
Why does this happen?
The mount command is running as root, I am mounting to a mount point owned by root. The server is serving a directory owned by root. I have no mapping configured anywhere on the client or the server. Why does this ACCESS command get issued as my user account and not as root.
If I change the mount command to NFSv4, these access requests are issued as UID: 0 and GID:0 (as expected. Root!)
What makes the client switch like this? It seems I have no control over this.
Any info help much appreciated.
nfs rpc
asked Nov 12 at 18:36
Aidan Walton
11
A little follow up on this. If I change to the mounted directory and touch a file as root, then on the wire for the CREATE Call I now see UID & GID of root. If I su to my own user account, I correctly see my UID and GID in the CREATE Call. So that's good. But this does not explain for me why the mount command decides to use my user account credentials to establish the mount point.
– Aidan Walton
2 days ago
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have been using NFS for several years and accepted its limitations in terms of security and lack of authentication etc. This was fine as I'm only using it in a small and secure network environment. Recently I upgraded my server to 18.04 LTS and decided to take a closer look at NFS with the aim of moving to using NFSv4. This has proved to be a headache for several reason, I'm running Ubuntu, Macs and Windows clients, so I was expecting a mixture of NFSv3 and NFSv4, but it proved to be a lot more difficult than I expected.
I have now spent days carefully trying to understand the subtleties of how the client and server exchange works on the wire. I have hit an issue that I just can not google the answer too. Maybe someone else can explain.
I have an Ubuntu server (18.04) running both NFSv3&4. I have configured an export and I share it out with: (rw,insecure,subtree_check,no_root_squash). I choose specifically not to use root squashing as I wanted to observe the exact behaviour when I attempt to mount from a client.
When I logged in as root on the client I issue the mount command:
mount -t nfs -o vers=3 mx:/mnt/shared_sun_NAS/Videos /mnt/Videos
sure enough it mounts....
When I look at the exchange on the wire I see the expected exchanges:
- Portmap - GETPORT Call NFS TCP
- Portmap - GETPORT Reply Port 2049
- NFS - NULL Call
- NFS - NULL Reply success
- Portmap - GETPORT Call MOUNT UDP
- Portmap - GETPORT Reply Port 65500 (I choose this port on the server)
- MOUNT - NULL Call
- MOUNT - NULL Reply success
- MOUNT - NULL Call
- MOUNT - NULL Reply success
- MOUNT - MNT Call /mnt/shared_sun_NAS/Videos
- MOUNT - MNT Reply success
- Portmap - GETPORT NFS TCP
- Portmap - GETPORT Reply Port 2049
- NFS - NULL Call
- NFS - NULL Reply success
- NFS - FSINFO Call FH:xxxx
- NFS - FSINFO Reply success
- NFS - PATHCONF Call FH:xxxx
- NFS - PATHCONF Reply success
- NFS - GETATTR Call FH:xxxx
- NFS - GETATTR Reply success: Dir mode 3770 uid:0 gid:5000 (exactly as on the server)
- NFS - NFSACL Call
- NFS - NFSACL Reply success
- NFS - FSINFO Call FH:xxxx
- NFS - FSINFO Reply success
- NFS - GETATTR Call FH:xxxx
- NFS - GETATTR Reply success: Dir mode 3770 uid:0 gid:5000
- NFS - ACCESS Call DH: xxxx [Check: RD LU MD XT DL]
- NFS - ACCESS Reply success [Allowed: RD LU MD XT DL]
Here I will stop and ask my question:
In each and every frame from 1-28 the RPC header shows:
Machine Name: Laplace
UID: 0
GID: 0
Aux GIDs [0, 5000] just exactly as my root user on the client.
Then as soon as the client moves to ACCESS commands RPC header changes as below:
Machine Name: Laplace
UID: 1000
GID: 1000
Aux GIDs [4...... 5000] just exactly as my user account on the client.
Why does this happen?
The mount command is running as root, I am mounting to a mount point owned by root. The server is serving a directory owned by root. I have no mapping configured anywhere on the client or the server. Why does this ACCESS command get issued as my user account and not as root.
If I change the mount command to NFSv4, these access requests are issued as UID: 0 and GID:0 (as expected. Root!)
What makes the client switch like this? It seems I have no control over this.
Any info help much appreciated.
nfs rpc
asked Nov 12 at 18:36
Aidan Walton
11
I have been using NFS for several years and accepted its limitations in terms of security and lack of authentication etc. This was fine as I'm only using it in a small and secure network environment. Recently I upgraded my server to 18.04 LTS and decided to take a closer look at NFS with the aim of moving to using NFSv4. This has proved to be a headache for several reason, I'm running Ubuntu, Macs and Windows clients, so I was expecting a mixture of NFSv3 and NFSv4, but it proved to be a lot more difficult than I expected.
I have now spent days carefully trying to understand the subtleties of how the client and server exchange works on the wire. I have hit an issue that I just can not google the answer too. Maybe someone else can explain.
I have an Ubuntu server (18.04) running both NFSv3&4. I have configured an export and I share it out with: (rw,insecure,subtree_check,no_root_squash). I choose specifically not to use root squashing as I wanted to observe the exact behaviour when I attempt to mount from a client.
When I logged in as root on the client I issue the mount command:
mount -t nfs -o vers=3 mx:/mnt/shared_sun_NAS/Videos /mnt/Videos
sure enough it mounts....
When I look at the exchange on the wire I see the expected exchanges:
- Portmap - GETPORT Call NFS TCP
- Portmap - GETPORT Reply Port 2049
- NFS - NULL Call
- NFS - NULL Reply success
- Portmap - GETPORT Call MOUNT UDP
- Portmap - GETPORT Reply Port 65500 (I choose this port on the server)
- MOUNT - NULL Call
- MOUNT - NULL Reply success
- MOUNT - NULL Call
- MOUNT - NULL Reply success
- MOUNT - MNT Call /mnt/shared_sun_NAS/Videos
- MOUNT - MNT Reply success
- Portmap - GETPORT NFS TCP
- Portmap - GETPORT Reply Port 2049
- NFS - NULL Call
- NFS - NULL Reply success
- NFS - FSINFO Call FH:xxxx
- NFS - FSINFO Reply success
- NFS - PATHCONF Call FH:xxxx
- NFS - PATHCONF Reply success
- NFS - GETATTR Call FH:xxxx
- NFS - GETATTR Reply success: Dir mode 3770 uid:0 gid:5000 (exactly as on the server)
- NFS - NFSACL Call
- NFS - NFSACL Reply success
- NFS - FSINFO Call FH:xxxx
- NFS - FSINFO Reply success
- NFS - GETATTR Call FH:xxxx
- NFS - GETATTR Reply success: Dir mode 3770 uid:0 gid:5000
- NFS - ACCESS Call DH: xxxx [Check: RD LU MD XT DL]
- NFS - ACCESS Reply success [Allowed: RD LU MD XT DL]
Here I will stop and ask my question:
In each and every frame from 1-28 the RPC header shows:
Machine Name: Laplace
UID: 0
GID: 0
Aux GIDs [0, 5000] just exactly as my root user on the client.
Then as soon as the client moves to ACCESS commands RPC header changes as below:
Machine Name: Laplace
UID: 1000
GID: 1000
Aux GIDs [4...... 5000] just exactly as my user account on the client.
Why does this happen?
The mount command is running as root, I am mounting to a mount point owned by root. The server is serving a directory owned by root. I have no mapping configured anywhere on the client or the server. Why does this ACCESS command get issued as my user account and not as root.
If I change the mount command to NFSv4, these access requests are issued as UID: 0 and GID:0 (as expected. Root!)
What makes the client switch like this? It seems I have no control over this.
Any info help much appreciated.
nfs rpc
nfs rpc
asked Nov 12 at 18:36
Aidan Walton
11
asked Nov 12 at 18:36
Aidan Walton
11
asked Nov 12 at 18:36
Aidan Walton
11
asked Nov 12 at 18:36
Aidan Walton
11
asked Nov 12 at 18:36
Aidan Walton
11
11
A little follow up on this. If I change to the mounted directory and touch a file as root, then on the wire for the CREATE Call I now see UID & GID of root. If I su to my own user account, I correctly see my UID and GID in the CREATE Call. So that's good. But this does not explain for me why the mount command decides to use my user account credentials to establish the mount point.
– Aidan Walton
2 days ago
add a comment |
A little follow up on this. If I change to the mounted directory and touch a file as root, then on the wire for the CREATE Call I now see UID & GID of root. If I su to my own user account, I correctly see my UID and GID in the CREATE Call. So that's good. But this does not explain for me why the mount command decides to use my user account credentials to establish the mount point.
– Aidan Walton
2 days ago
A little follow up on this. If I change to the mounted directory and touch a file as root, then on the wire for the CREATE Call I now see UID & GID of root. If I su to my own user account, I correctly see my UID and GID in the CREATE Call. So that's good. But this does not explain for me why the mount command decides to use my user account credentials to establish the mount point.
– Aidan Walton
2 days ago
A little follow up on this. If I change to the mounted directory and touch a file as root, then on the wire for the CREATE Call I now see UID & GID of root. If I su to my own user account, I correctly see my UID and GID in the CREATE Call. So that's good. But this does not explain for me why the mount command decides to use my user account credentials to establish the mount point.
– Aidan Walton
2 days ago
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1092302%2fwhen-using-nfsv3-uid-gid-in-rpc-headers-from-client-changes-unexpectedly%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
A little follow up on this. If I change to the mounted directory and touch a file as root, then on the wire for the CREATE Call I now see UID & GID of root. If I su to my own user account, I correctly see my UID and GID in the CREATE Call. So that's good. But this does not explain for me why the mount command decides to use my user account credentials to establish the mount point.
– Aidan Walton
2 days ago