Description of problem: Mounting an nfs directory on a Mageia 3 client from a Mandriva 2010.1 system is messed up. It seems that some sort of uid/gid translation is taking place, which is inappropriate. Setting-- A directory on a Mandriva 2010.1 system. /disk/home This has a whole bunch of user directories on it. One of them is mine. On the Mandriva system I have uid 225, gid 25. I installed a Mageia 3 system, on which I had my username the same, but with uid 500. I nfs mounted the directory M2010:/disk/home onto /disk/home on the Mageia system. The gid of my home directory was now suddenly 500 instead of the 225 it had on the M2010 nfs server. I now copied all of the user entries from the /etc/passwd on the M2010 system to the /etc/passwd file on the Mageia system, including my entry with uid defined for me of 225. I also removed the entry for me from that file that had me listed as uid 500. But on the nfs mounted directory, my home directory, which had uid 225 on the server, had uid 500 even after I changed /etc/passwd. Something is doing a uid translation, which I think is a huge security hole. Just becasue two users have the same names on the different machines does NOT mean they are the same user. Also if there is a uid with no username in passwd on the new system, instead of displaying the username as it always used to do, it displays the name nobody. The gids are even weirder. I get bunches of gids with number 2^32-2 displayed, gids which even exist on the /etc/group of the client, but have a different name from that on the server. I recently discovered that this seems to be a problem with nfs4.0. If I put in and explicit vers=3 option on mounting or in fstab, everthing behaves properly as it always used to behave. But nfs4.0 is the default. (since the server is Mandriva 2010.1 it certainly supports 4.0, but remote mounts have never behaved in this way even when mounted vers=4.0 on my Madriva machines.) I have marked this as critical because of the security implications. Reproducible: Steps to Reproduce:
It sems to be a problem from Mandriva 20101 to Mageia 3 (I have no idea whether other versions also have the problem). If I mount a directory from a Mageian3 server to a Mageia3 client I get reasonable behaviour From the output to the mount command boson:/alt/mageia on /mageia type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=142.103.234.01,local_lock=none,addr=142.103.234.02) and ls -l /mageia/3 total 20 drwxr-xr-x 5 root root 4096 Jan 26 01:28 . drwxr-xr-x 6 root root 4096 Jan 27 03:02 .. drwxr-xr-x 8 2000 2000 4096 May 18 2013 i586 drwxr-xr-x 2 2000 2000 4096 May 18 2013 Mageia-3-LiveCD-KDE4-en-i586-CD drwxr-xr-x 2 2000 2000 4096 May 18 2013 Mageia-3-LiveDVD-KDE4-i586-DVD Ie, it is not translating unkown gids to 2^32-2 nor is it replacing an unknown uid with user nobody. So there seems to be some severe incompatibility between nfs on Mageia 3 and on Mandriva 2010.1
A further bit of information-- I tried mounting a backup of the home filesystem which was on a backup machine. That backup machine was also a Mageia 3 machine. Mounting from it as a server with nfs version 4.0 and all of the uids and gids displayed fine. Thus it seems that the uid/gid translation is taking place between a Mandriva 2010.1 server and a Mageia 3 client. It gets more and more bizarre.
It probably has something to do with idmapper, but why it would fail so spectaculary with Madriva on the server, but not with MG3 on the server, I have no idea. And how can one setup idmapper to behave?
Everything you've described is how NFSv4 behaves by design, as I understand it, and as you pointed out, if you want NFSv3 behavior, you can explicitly configure it to use that. This is not a bug.
Status: NEW => RESOLVEDResolution: (none) => INVALID
With current NFSv4 implementation, the process in charge of name <-> uid mapping on both server and client side is rpc.idpmad, the idmapper. By default, it uses NSS, but nothing prevents you to override specific mappings. See idmapd.conf (5) for details, and specifically the [static] section. Also, you have to make sure the process is running on both side, which is supposed to be automatically handled by service scripts, otherwise you'll end up with file owned by unknown user.
CC: (none) => guillomovitch
If it is "expected behaviour, why does it work badly going from a Mandriva 2010.1 server to a Mag 3 client, but works properly going from a Mag 3 server to a Mageia 3 client. Both partitions are identical on identical ext3 partitions (One is a backup of the other). The only difference is that one is a Mandriva 2010.1 server and the other a Mageia 3 server. Using nfs4 on both. The group id is not working well at all. It is reporting 2^32-1 as a number even though that group gid is defined in /etc/groups on both systems when the max gid is, I believe 2^16-2. As I said, I think that the problem IS the idmapper, and it has not, as far as I know, be overridden on either system. I certainly have not done so. So, yes, if it behaves inconsistantly, it is a bug. (and if it behaves irrationally it is a bug, even if it is working as designed, but I agree it is then not a Mageia bug). And as I pointed out, it is a security hole.
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
> And as I pointed out, it is a security hole. I don't see why using UID equality on both server and client would be safer than using name equality. In both case, the user can select anything if he has admin privileges on client side, which make it equally insecure: if you don't trust the client, don't use NFS at all, or use NFSv4 with adequate security level, meaning Kerberos.
Because the system is confused. For example, using the new uid 225 for unru I was able to log in and edit files in my home directory, except that vim refused because it did not have permission to write its .viminfo file ( and that was owned by me and had write permission to me.) Ie, the system was confused as to what my uid actually was. The translation is not seemless. As I would expect-- there are far too many places where that kind of translation could go wrong. It should at least be a option to shut it off so there is no translation of uids.
You're confusing your current situation with a generic issue: just because it doesn't work for you right now doesn't make name-based user identification less safe than uid-based identification. And as already said, there is already a mechanism to avoid name-based user identification, which is to force NFSv2/v3 usage, instead of NFSv4. See nfsmount.conf (5) for details. BTW, a bug tracker is not a support channel. If you're not able to demonstrate a bug in mageia nfs-utils package, meaning a failure to provide documented behaviour, once properly configured, you're unlikely to get better audience.
? In theory yes, both could work. But if it does not work properly in practice, yes, in my particular situation right now, then that suggests that there is a bug. I will admit that I did not understand what was doing the translation and that nfs4 used translation. The question is whether or not that translation is buggy. I would suggest that it is. a)vim was unable to save its state, and got a permission denied, even when it was able to edit files with the same permissions and ownership without trouble. b)gids were displayed with gid of 2^32-2 rather than 2^16-2 which is the usual max gid. c) When mounting of exactly the same directories and files from a Mageia 3 system things worked as expected, while from a Mandriva 2010.1 system they were not. All of these suggest that there is something wrong. You may be right that what is wrong is some configuration on my part. But I am using an "out of the box" configuration set up by Mageia and Mandriva, so that suggests one or the other is buggy. Not sure wwhat you would need to demonstrate a bug.
Claiming than something not working out of the box is buggy is not going to convince anyone, and especially not me. And in order to prove than user mapping is wrong, you'd better check first than: - it is properly configured on both side, meaning using an identical NFSv4 domain - it is running on both side - both client and server negociated NFSv4 properly Once again, you'd better read adequate documentation first, ask support on adequate channel second.
Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: REOPENED => RESOLVEDResolution: (none) => OLD