I have a few systems on site which have common users installed with "wrong" UID values from the rest of the machines, and particularly those installed from a "live" CD which created one or more odd IDs when "install to disk" was used.
I remember using "UID mapping tables" to cause an NFS access from "joe" on the client to use the UID of "joe" in the request sent to the NFS server. I can't recall if that was in Linux, or some other OS, I was supporting Xenix, AIX, Solaris, SunOS, and HP-UX at the time. Oh, and Dell's brief jump into SV5r4 on PC.
If this is supported it would be miles easier than shuffling the UIDs on the clients, obviously. I though there was a mount option but I don't see it, and it's been a good decade since I did this and I can't remember details.
I thought I was remembering the map_static option, but it is not recognized in exports, not are map_daemon or no_map_identity. (see: http://ftp.sunet.se/LDP/LDP/nag2/x-087-2-nfs.exports.html)
What do I miss, the doc says it's there, the software disagrees.
On Tue, 2010-03-09 at 19:43 -0500, Bill Davidsen wrote:
I have a few systems on site which have common users installed with "wrong" UID values from the rest of the machines, and particularly those installed from a "live" CD which created one or more odd IDs when "install to disk" was used.
NFS 4 is supposed to be able to handle this. That might be a starting point for your reading.
Bill Davidsen davidsen@tmr.com writes:
I have a few systems on site which have common users installed with "wrong" UID values from the rest of the machines, and particularly those installed from a "live" CD which created one or more odd IDs when "install to disk" was used.
In theory NFSv4 does the remapping, but I coudn't find it either. It was far easier and faster to run a "find / -user uid -print" and just fix up the uids.
It is things like this I miss from netbsd and openbsd. They assigned UID's to all their packages (eg. rpm's) and it didn't matter which order one installed things in, the UID's were always the same.
-wolfgang
I have a few systems on site which have common users installed with "wrong" UID values from the rest of the machines, and particularly those installed from a "live" CD which created one or more odd IDs when "install to disk" was used.
I remember using "UID mapping tables" to cause an NFS access from "joe" on the client to use the UID of "joe" in the request sent to the NFS server. I can't recall if that was in Linux, or some other OS, I was supporting Xenix, AIX, Solaris, SunOS, and HP-UX at the time. Oh, and Dell's brief jump into SV5r4 on PC.
If this is supported it would be miles easier than shuffling the UIDs on the clients, obviously. I though there was a mount option but I don't see it, and it's been a good decade since I did this and I can't remember details.
I thought I was remembering the map_static option, but it is not recognized in exports, not are map_daemon or no_map_identity. (see: http://ftp.sunet.se/LDP/LDP/nag2/x-087-2-nfs.exports.html)
What do I miss, the doc says it's there, the software disagrees.
In the Debian-Ubuntu world, there is nfs-user-server package (as opposed to the "usual" nfs-kernel-server) package where the map_* options work (map_daemon when you install ugidd), so that is probably the origin. Even CentOS 5.4 no longer has a similar man page for exports.
nfsv4's idmapd maps ids but I don't think that, even though the credentials that are exchanged are "user@domain", AFAIK it will only map the usernames on the client and the server if their uids match.
Wolfgang S. Rupprecht wrote:
Bill Davidsen davidsen@tmr.com writes:
I have a few systems on site which have common users installed with "wrong" UID values from the rest of the machines, and particularly those installed from a "live" CD which created one or more odd IDs when "install to disk" was used.
In theory NFSv4 does the remapping, but I coudn't find it either. It was far easier and faster to run a "find / -user uid -print" and just fix up the uids.
The problem is that it becomes painfully complex, before I can make 'joe' user 500 I have to move the user who is 500 to another uid... and as you say nfs4 seems to support a lookup security model.
The issue may be that nfs4 doesn't seem to be working, mount.nfs4 gives a failure, so perhaps job one will be to find out why the export isn't working. NFS is so insecure by nature that it would be nice not to fight pseudo-security.
It is things like this I miss from netbsd and openbsd. They assigned UID's to all their packages (eg. rpm's) and it didn't matter which order one installed things in, the UID's were always the same.
Thanks for the thoughts, I will keep looking.
-wolfgang
Bill Davidsen wrote:
Wolfgang S. Rupprecht wrote:
Bill Davidsen davidsen@tmr.com writes:
I have a few systems on site which have common users installed with "wrong" UID values from the rest of the machines, and particularly those installed from a "live" CD which created one or more odd IDs when "install to disk" was used.
In theory NFSv4 does the remapping, but I coudn't find it either. It was far easier and faster to run a "find / -user uid -print" and just fix up the uids.
The problem is that it becomes painfully complex, before I can make 'joe' user 500 I have to move the user who is 500 to another uid... and as you say nfs4 seems to support a lookup security model.
The issue may be that nfs4 doesn't seem to be working, mount.nfs4 gives a failure, so perhaps job one will be to find out why the export isn't working. NFS is so insecure by nature that it would be nice not to fight pseudo-security.
It is things like this I miss from netbsd and openbsd. They assigned UID's to all their packages (eg. rpm's) and it didn't matter which order one installed things in, the UID's were always the same.
Thanks for the thoughts, I will keep looking.
I did, and I find that for one time problems sshfs is a useful solution, while I'm still trying to figure out why I can't do an NFS4 mount of the filesystem. Looks like the server is restricting to nfsv3 because ???
-wolfgang
On Sat, 2010-03-13 at 18:11 -0500, Bill Davidsen wrote:
The issue may be that nfs4 doesn't seem to be working, mount.nfs4 gives a failure, so perhaps job one will be to find out why the export isn't working.
Are all the computers using the same OS? Prior Fedora releases used a lesser (than 4) version of NFS by default, and would require manual configuration to use NFS4. Other distros probably have the same issue.
NFS is so insecure by nature that it would be nice not to fight pseudo-security.
Yes. I'd use it in a network where you trust people not to exploit it, and can manage the configuration to connect the right user names with each other. But where you can't trust users not to exploit it, or use it incorrectly, or your network is exposed to outsiders (unencrypted wireless, running as part of someone else's LAN, etc.), you'd want something better.
Tim wrote:
On Sat, 2010-03-13 at 18:11 -0500, Bill Davidsen wrote:
The issue may be that nfs4 doesn't seem to be working, mount.nfs4 gives a failure, so perhaps job one will be to find out why the export isn't working.
Are all the computers using the same OS? Prior Fedora releases used a lesser (than 4) version of NFS by default, and would require manual configuration to use NFS4. Other distros probably have the same issue.
Yes, and I can't seem to get nfs4 working on the server side. I have tried adding flags to the exportfs call but the ones in the manual seem to be rejected. This is a set of fully updated Fedora 9 boxes, and mount.nfs4 is present, but the options for export seem unsupported.
I can test using the /etc/exports file, but exporting things before doing the mount on them seems to have it's own issues, and the determination of what to mount for export is definitely done many seconds after boot. The NFS3 moutns work fine, but access is broken.
NFS is so insecure by nature that it would be nice not to fight pseudo-security.
Yes. I'd use it in a network where you trust people not to exploit it, and can manage the configuration to connect the right user names with each other. But where you can't trust users not to exploit it, or use it incorrectly, or your network is exposed to outsiders (unencrypted wireless, running as part of someone else's LAN, etc.), you'd want something better.
Network security isn't the issue here, it's all a matter of uid at the moment.
On Sun, 2010-03-14 at 17:37 -0400, Bill Davidsen wrote:
Tim wrote:
On Sat, 2010-03-13 at 18:11 -0500, Bill Davidsen wrote:
The issue may be that nfs4 doesn't seem to be working, mount.nfs4 gives a failure, so perhaps job one will be to find out why the export isn't working.
Are all the computers using the same OS? Prior Fedora releases used a lesser (than 4) version of NFS by default, and would require manual configuration to use NFS4. Other distros probably have the same issue.
Yes, and I can't seem to get nfs4 working on the server side. I have tried adding flags to the exportfs call but the ones in the manual seem to be rejected. This is a set of fully updated Fedora 9 boxes, and mount.nfs4 is present, but the options for export seem unsupported.
I can test using the /etc/exports file, but exporting things before doing the mount on them seems to have it's own issues, and the determination of what to mount for export is definitely done many seconds after boot. The NFS3 moutns work fine, but access is broken.
NFS is so insecure by nature that it would be nice not to fight pseudo-security.
Yes. I'd use it in a network where you trust people not to exploit it, and can manage the configuration to connect the right user names with each other. But where you can't trust users not to exploit it, or use it incorrectly, or your network is exposed to outsiders (unencrypted wireless, running as part of someone else's LAN, etc.), you'd want something better.
Network security isn't the issue here, it's all a matter of uid at the moment.
---- I don't know what you have or haven't done or if you have configured idmapd and started rcpidmapd service but here is some instructions...
http://fedorasolved.org/post-install-solutions/nfsv4-fedora
Craig
Craig White wrote:
On Sun, 2010-03-14 at 17:37 -0400, Bill Davidsen wrote:
Tim wrote:
On Sat, 2010-03-13 at 18:11 -0500, Bill Davidsen wrote:
The issue may be that nfs4 doesn't seem to be working, mount.nfs4 gives a failure, so perhaps job one will be to find out why the export isn't working.
Are all the computers using the same OS? Prior Fedora releases used a lesser (than 4) version of NFS by default, and would require manual configuration to use NFS4. Other distros probably have the same issue.
Yes, and I can't seem to get nfs4 working on the server side. I have tried adding flags to the exportfs call but the ones in the manual seem to be rejected. This is a set of fully updated Fedora 9 boxes, and mount.nfs4 is present, but the options for export seem unsupported.
I can test using the /etc/exports file, but exporting things before doing the mount on them seems to have it's own issues, and the determination of what to mount for export is definitely done many seconds after boot. The NFS3 moutns work fine, but access is broken.
NFS is so insecure by nature that it would be nice not to fight pseudo-security.
Yes. I'd use it in a network where you trust people not to exploit it, and can manage the configuration to connect the right user names with each other. But where you can't trust users not to exploit it, or use it incorrectly, or your network is exposed to outsiders (unencrypted wireless, running as part of someone else's LAN, etc.), you'd want something better.
Network security isn't the issue here, it's all a matter of uid at the moment.
I don't know what you have or haven't done or if you have configured idmapd and started rcpidmapd service but here is some instructions...
At some point you just have to assume it's broken or documented so poorly that source code is your only hope. I have done all that stuff, and not only do I get "no such file or directory" with nfs4, but wireshark tells me the server if still using v3. All the things in that document were done, I did change "nobody" to "nfsnobody" in idmapd.conf and restart, but that make no difference.
It seems no one I can reach has actually ever made nfsv4 work on FC9, even thought it's documented to do so. Probably another thing a level ten guru can do using some trick never documented.
Thanks much for the link to the doc, I can now feel comfortable that I didn't miss something.