Launchpad has imported 42 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=876705.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-11-14T18:52:45+00:00 Maurizio wrote: Description of problem: When listing an nfs4 mounted directory an incorrect ownership of -2 is shown for some users. Version-Release number of selected component (if applicable): nfs client (Fedora 17): nfs-utils-1.2.6-5.fc17.i686 kernel-PAE-3.6.5-1.fc17.i686 nfs server (Fedora 16): nfs-utils-1.2.5-5.fc16.i686 kernel-PAE-3.3.5-2.fc16.i686 How reproducible: by listing an NFS4 mounted directory with files owned by many users. Steps to Reproduce: 1. Mount via NFS4 an export containing files owned by more than 200 different users (e.g. /var/spool/mail/) 2. Do "ls -l <mountpoint>" Actual results: for some users the ownership is incorrectly given as 4294967294 Expected results: the owner of all files should be mapped correctly Additional info: in /proc/keys there is a listing of all cached uid mappings, the user that are not listed correctly are not present in the list. Strangely, all keys are shown as "permanent" instead of having an expiration time of 600 seconds. Also they are contributing (flag Q) to the quota. in /proc/key-users you can find the current maximum allowed number of keys for the root user (200). Bug https://bugzilla.redhat.com/show_bug.cgi?id=847084 probably has the same origin; however that bug has been closed as NOTABUG. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/0 ------------------------------------------------------------------------ On 2012-11-15T08:56:06+00:00 Steve wrote: *** Bug 847084 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/1 ------------------------------------------------------------------------ On 2012-11-15T09:01:16+00:00 Steve wrote: David, Would it make sense to patch the kernel so the maxkeys/root_maxkeys are set to a more reasonable value? Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/2 ------------------------------------------------------------------------ On 2012-11-15T09:15:05+00:00 Luca wrote: I have given a look at the relevant sources for the fedora kernel (upstream it is just the same). It appears that nfsid keys should be created within the keyring keyring = key_alloc(&key_type_keyring, ".id_resolver", 0, 0, cred, (KEY_POS_ALL & ~KEY_POS_SETATTR) | KEY_USR_VIEW | KEY_USR_READ, KEY_ALLOC_NOT_IN_QUOTA); in idmap.c However they do still count toward the quota of root (whence the problem). This is quite surprising and, unless I am misrepresenting the situation, it could be a bug somewhere else. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/3 ------------------------------------------------------------------------ On 2013-02-03T22:09:14+00:00 Maurizio wrote: The issue is still there on a fresh installation of a Fedora 18. Now this is quite unfortunate: like this NFS4 is unreliable and quite unusable especially on systems like mail servers that typically handle files with many differing ownerships in a common directory. Is this going to be fixed? Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/4 ------------------------------------------------------------------------ On 2013-03-13T05:35:34+00:00 Maurizio wrote: The problem is still present after a fresh update of the client: nfs client (Fedora 18): nfs-utils-1.2.7-3.fc18.i686 kernel-PAE-3.8.2-206.fc18.i686 nfs server (Fedora 16): nfs-utils-1.2.5-5.fc16.i686 kernel-PAE-3.3.5-2.fc16.i686 The description of the problem above still applies. Moreover nothing is written in /var/log/messages Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/7 ------------------------------------------------------------------------ On 2013-04-10T08:27:53+00:00 David wrote: I don't see the issue between 2 Fedora 18 machines. Unfortunately, our Fedora and Ubuntu clients do run into this problem all the time with the home and mail directories, which are on RHEL 6 servers. Could it be that the bug was fixed in recent Fedora kernels, but that RHEL 6 is still waiting for a fix? Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/8 ------------------------------------------------------------------------ On 2013-04-10T09:21:00+00:00 Anders wrote: This is what I use on our Fedora machines (1000 is enough for us ATM): /etc/sysctl.d/nfsv4_idmap_maxkeys: # NFSv4 idmap entries are counted against a very low quota # https://bugzilla.redhat.com/show_bug.cgi?id=876705 kernel.keys.root_maxkeys = 1000 kernel.keys.maxkeys = 1000 Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/9 ------------------------------------------------------------------------ On 2013-04-10T12:30:42+00:00 Maurizio wrote: (In reply to comment #6) > I don't see the issue between 2 Fedora 18 machines. After a quick check I realized that with two Fedora 18 the uid mapping mechanism wasn't working at all (strangely). If this is the case it is no wonder that you didn't see the issue in that case. Could you check? Just create the same username with different UIDs on the two machines. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/10 ------------------------------------------------------------------------ On 2013-04-10T13:03:36+00:00 Anders wrote: This might be a starting point: http://comments.gmane.org/gmane.linux.nfs/51842 Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/11 ------------------------------------------------------------------------ On 2013-04-10T22:10:22+00:00 Luca wrote: Actually, I believe the change in behaviour is documented here: http://comments.gmane.org/gmane.linux.nfs/46028 When kerberos is not in use the client now just sends uid/gid pairs by default. I still wonder if this might masking an actual bug on nfs keys being counted as in quota, though. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/12 ------------------------------------------------------------------------ On 2013-04-15T13:38:17+00:00 Maurizio wrote: (In reply to comment #6) > I don't see the issue between 2 Fedora 18 machines. I wanted to investigate the issue between two Fedora 18 machines. Unfortunately I couldn't find a way to activate the uid mapping mechanism. Everything I tried had simply results compatible with nfs version 3. My test case was: 1. create a user "testnfs" on both the server and client with different UIDs 2. create a file on the server with (local) ownership by testnfs 3. nfs-mount the directory on the client machine and investigate the ownership of the file by the (local on the client) testnfs user. I espect ownership (e.g. uid is remapped), which is *not* the case. --- The same experiment carried on a Fedora 16 server, kernel 3.3.5-2.fc16.i686.PAE nfs-utils-1.2.5-5.fc16.i686, on the contrary gave the expected uid remapping. --- Not that I actually *need* remapping (on the contrary!), this is just to understand whether the problem is transient, and solved for the future or not. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/13 ------------------------------------------------------------------------ On 2013-04-17T10:57:57+00:00 David wrote: Indeed, between fedora 18 machines, idmap seems to have no effect. The only reason why I didn't see any files owned by "nobody" was, because we use LDAP as central user database, so all numerical user id's could be resolved identically at server and client side. But if I have a local user with different user id, it will show up as a numerical id on the other side. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/14 ------------------------------------------------------------------------ On 2013-04-17T21:13:08+00:00 Maurizio wrote: in /sys/module/nfs/parameters/nfs4_disable_idmapping and /sys/module/nfsd/parameters/nfs4_disable_idmapping the default value is Y (which justifies the fact that idmapping seems disabled between two fedora 18 machines. However, twiggling with those files did not allow me to accomplish a fully functional nfs-id-mapping as with a fedora 16 nfs server: apparently the uids are correctly remapped according to the local username, but actual access to the files obey to "non-remapped" uid; a quite weird situation. I guess I am missing something, or perhaps uid remapping support is currently broken in nfs 4.1 Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/15 ------------------------------------------------------------------------ On 2013-09-13T14:51:09+00:00 David wrote: With respect to the mapping cache capacity, there are two problems that need addressing: (1) The capacity of a keyring isn't sufficient (~1024 on 32-bits, ~512 on 64-bits). I have patches to expand this, but they're not quite upstream yet. This limits the size of the cache. (2) The default maximum number of keys (quota) is only 200. This can be altered from the running kernel as mentioned in comment 7 by tweaking sysctls for the moment. Ideally, though, kernel-wrought keys like this shouldn't be counted towards quota - something that will require a patch. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/18 ------------------------------------------------------------------------ On 2013-10-02T11:04:03+00:00 David wrote: Patches to expand keyring capacity have been committed to the upstream security tree and will hopefully go to Linus in the next merge window: http://git.kernel.org/cgit/linux/kernel/git/jmorris/linux- security.git/commit/?h=next&id=b2a4df200d570b2c33a57e1ebfa5896e4bc81b69 Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/21 ------------------------------------------------------------------------ On 2013-10-02T12:49:40+00:00 Josh wrote: We're actually already carrying those patches in F20 and rawhide. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/22 ------------------------------------------------------------------------ On 2013-10-18T21:02:10+00:00 Justin wrote: *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/26 ------------------------------------------------------------------------ On 2014-01-03T22:05:29+00:00 Justin wrote: *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/29 ------------------------------------------------------------------------ On 2014-01-08T14:28:12+00:00 Josh wrote: F19 won't get this until it is rebased to 3.13. If the original reporter has since moved to F20, we can close this as NEXTRELEASE. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/30 ------------------------------------------------------------------------ On 2014-01-08T15:45:45+00:00 Maurizio wrote: (In reply to Josh Boyer from comment #19) > F19 won't get this until it is rebased to 3.13. If the original reporter > has since moved to F20, we can close this as NEXTRELEASE. I (the original reporter) just moved to F20. The problem is still present: ----------------------------------------------------------------------- # mv [to a directory with more than 200 different owners] # echo "200" > /proc/sys/kernel/keys/root_maxkeys # ls -l [...] -rw------- 1 4294967294 mail 2958131 Jan 7 11:56 xxxx [...] # echo "10000" > /proc/sys/kernel/keys/root_maxkey # ls -l [...] -rw------- 1 xxxx mail 2958131 Jan 7 11:56 xxxx [...] ----------------------------------------------------------------------- should I change the Version from 19 to 20? Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/31 ------------------------------------------------------------------------ On 2014-01-08T17:03:40+00:00 Josh wrote: David, do you know why Maurizio is still seeing this given that we're carrying the updated keyring patches? Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/32 ------------------------------------------------------------------------ On 2014-01-08T17:53:57+00:00 Maurizio wrote: I just rechecked after a "yum update" and a reboot. I can confirm the problem. info: $ uname -r 3.12.6-300.fc20.i686+PAE $ rpm -q nfs-utils nfs-utils-1.2.8-6.0.fc20.i686 (I also removed my only local entry in /etc/sysctl.d that changed the value of /proc/sys/kernel/keys/root_maxkeys to 10000, just to make sure that the default value is still 200). However keep in mind that the NFS server is a fedora 16: $ uname -r 3.3.5-2.fc16.i686.PAE $ rpm -q nfs-utils nfs-utils-1.2.5-5.fc16.i686 Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/33 ------------------------------------------------------------------------ On 2014-01-25T01:20:15+00:00 Edgar wrote: I have a similar (or the same?) problem. Since Fedora 16 our nfsv4 clients will show the owner or group of a file as "4294967294" when there are to many different owners or groups when listing a directory (using "ls -l"). The problem still exists on Fedora 19 and Fedora 20. I have tried the test from comment #20 (with an added "e" in the last line containing "root_maxkey"). But I see no difference if /proc/sys/kernel/keys/root_maxkeys is 200 or 10000. I have tested it with kernel-3.12.8-300.fc20.x86_64 and nfs- utils-1.2.9-2.1.fc20.x86_64 . Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/34 ------------------------------------------------------------------------ On 2014-01-25T07:59:54+00:00 Maurizio wrote: Sorry, I missed an 's' (not an 'e') in the command (cut/paste problem), so the command is actually: # echo "10000" > /proc/sys/kernel/keys/root_maxkeys perhaps after the command it is better if you clean the keys with # nfsidmap -c This does the trick for us, it is strange that it does not change anything to you! If the change works, then you can make this happen at boot by creating a file in /etc/sysctl.d/ with a name like "99-local.conf" containing # Keys for nfs kernel.keys.root_maxkeys = 10000 (In reply to Edgar Hoch from comment #23) > I have a similar (or the same?) problem. Since Fedora 16 our nfsv4 clients > will show the owner or group of a file as "4294967294" when there are to > many different owners or groups when listing a directory (using "ls -l"). > > The problem still exists on Fedora 19 and Fedora 20. > > I have tried the test from comment #20 (with an added "e" in the last line > containing "root_maxkey"). But I see no difference if > /proc/sys/kernel/keys/root_maxkeys is 200 or 10000. > > I have tested it with kernel-3.12.8-300.fc20.x86_64 and > nfs-utils-1.2.9-2.1.fc20.x86_64 . Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/35 ------------------------------------------------------------------------ On 2014-01-25T08:46:28+00:00 Edgar wrote: Sorry, of course, I have added a "s", not a "e" - my error in the text of comment #23. Now I have created a file /etc/sysctl.d/99-maxkeys.conf with content as you suggested in comment #24. After a reboot, "cat /proc/sys/kernel/keys/root_maxkeys" prints "10000". Then I called "ls -l" on a list of all home directories (several hundred), and the problem still exists: The first directories are displayed with the correct username and groupname, and somewhere in the middle the remaining directories (and files, of course) with new usernames and groupnames are displayed as "4294967294". /proc/keys contains 529 lines. In a previous try, with /proc/sys/kernel/keys/root_maxkeys having the default value of 200, /proc/keys had about 150 lines. I have retried this configuration again - currently /proc/keys has 205 lines. Immediate after reboot, /proc/keys contains 14 lines. I see that increasing the value of /proc/sys/kernel/keys/root_maxkeys will map more file uids and gids to the correct name. But even if the value is much bigger than the number of registered users and groups not all uids and gids are mapped. The nfs server which I have used for this test runs Fedora 19, currently with kernel-3.11.7-200.fc19.x86_64 because its a production server in use which I should not reboot too often. We use nis for distributing the users on the hosts. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/36 ------------------------------------------------------------------------ On 2014-01-25T08:53:12+00:00 Edgar wrote: Additional info: "nfsidmap -c" have not solved the problem. /proc/keys was cleared (except of some "basic" values), but the nfs idmap problem still occured after listing the nfs directories / files. This is the reason why I have tried the file /etc/sysctl.d/99-maxkeys.conf so /proc/sys/kernel/keys/root_maxkeys have the right value (10000) immediate after boot. But this haven't solved the problem, too. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/37 ------------------------------------------------------------------------ On 2014-01-25T10:00:01+00:00 Maurizio wrote: we also use NIS, our nfs server is older than yours (Fedora 16, kernel 3.3.5-2.fc16.i686.PAE... however we only have slightly more than 200 users, so we barely see the problem with the default 200 value for root_maxkeys. However we do see if if we purposefully decrease the value from 200 to, say, 10. What comes in mind is that perhaps there is a maximal value (512?) for the number of keys, or perhaps you hit against the default maximum root_maxbytes (defaults to 20000). You could try to increase it as well... (In reply to Edgar Hoch from comment #26) > Additional info: > > "nfsidmap -c" have not solved the problem. /proc/keys was cleared (except of > some "basic" values), but the nfs idmap problem still occured after listing > the nfs directories / files. > > This is the reason why I have tried the file /etc/sysctl.d/99-maxkeys.conf > so /proc/sys/kernel/keys/root_maxkeys have the right value (10000) immediate > after boot. But this haven't solved the problem, too. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/38 ------------------------------------------------------------------------ On 2014-01-25T17:44:05+00:00 Anders wrote: Ah, using NIS/YP, try the *_tw_* workaround from https://bugzilla.redhat.com/show_bug.cgi?id=740024#c6 Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/39 ------------------------------------------------------------------------ On 2014-01-25T20:01:00+00:00 Maurizio wrote: I presume you refer to: echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse personally I do not think there is a relation, however no problems in trying that, however you should be more specific, the above setting has to be done on the NFS client, the NFS server, the NIS server? (In reply to Anders Blomdell from comment #28) > Ah, using NIS/YP, try the *_tw_* workaround from > https://bugzilla.redhat.com/show_bug.cgi?id=740024#c6 Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/40 ------------------------------------------------------------------------ On 2014-01-27T01:28:19+00:00 Edgar wrote: (In reply to Maurizio Paolini from comment #29) > I presume you refer to: > > echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle > echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse Setting net.ipv4.tcp_tw_recycle and net.ipv4.tcp_tw_reuse didn't help in my case. First I have tried this on the nfs client and then on the nfs client and nfs server too. I have used the following equalent commands: sysctl net.ipv4.tcp_tw_recycle=1 sysctl net.ipv4.tcp_tw_reuse=1 But I tried another thing: I have increased the value kernel.keys.root_maxbytes. The default was 20000. First I have increased only kernel.keys.root_maxbytes, leaving kernel.keys.root_maxkeys at default value (200), but this didn't help. Then I have increased kernel.keys.root_maxkeys too (again). Now all uids and gids on the nfs filesystems are mapped to the correct username, no "4294967294" is displayed anymore. It seems this solves the "4294967294" nfs problem for me. I did the following on the nfsv4 client (nfs server was unchanged resp. set to the same state as before the tests): sysctl kernel.keys.root_maxkeys=10000 sysctl kernel.keys.root_maxbytes=200000 I don't know how big the values should be, but it seems they are big enought for our configuration now. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/41 ------------------------------------------------------------------------ On 2014-01-27T04:33:24+00:00 Maurizio wrote: Fine... we then should change the name of this bug to include also the "maxbytes" :-) of course the point is that there should be no such a barrier on a production and historical filesystem like NFS, especially in the complete absense of any error message or indications of any kind on how to solve it (it can byte you very hard if e.g. there is a "sendmail" running on the NFS client with the mailboxes exported from a NFS server, like we have) Did someone have a check to comment #3 above by Luca Giuzzi? It seems very straight to the point, perhaps pointing to a bug in the keys implementation! (In reply to Edgar Hoch from comment #30) >[...] > But I tried another thing: > I have increased the value kernel.keys.root_maxbytes. The default was 20000. > First I have increased only kernel.keys.root_maxbytes, leaving > kernel.keys.root_maxkeys at default value (200), but this didn't help. > Then I have increased kernel.keys.root_maxkeys too (again). Now all uids and > gids on the nfs filesystems are mapped to the correct username, no > "4294967294" is displayed anymore. > > > It seems this solves the "4294967294" nfs problem for me. > I did the following on the nfsv4 client (nfs server was unchanged resp. set > to the same state as before the tests): > > sysctl kernel.keys.root_maxkeys=10000 > sysctl kernel.keys.root_maxbytes=200000 > > I don't know how big the values should be, but it seems they are big enought > for our configuration now. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/42 ------------------------------------------------------------------------ On 2014-02-24T13:52:57+00:00 Justin wrote: *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.13.4-200.fc20. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/43 ------------------------------------------------------------------------ On 2014-02-24T16:49:14+00:00 Edgar wrote: The problem still exists in kernel kernel-3.13.4-200.fc20.x86_64. The parameters values are still too low. # sysctl -a|grep kernel.keys.root kernel.keys.root_maxbytes = 20000 kernel.keys.root_maxkeys = 200 I think there should be no fixed limit at all for these values (or at least a very high, to prevent an error loop to consume unlimited memory). The kernel should allocate as much memory it needs to save all usernames, uids, gids, etc that exists on that system (including nis, ldap, etc.). The list of usernames, groupnames, uids, is limited because the files which contains the list have a limited lenght and usernames etc. are not generated dynamically while the system is running (except a fixed amount, for example by new packages, or manually by the system administrator). Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/44 ------------------------------------------------------------------------ On 2014-05-21T19:37:41+00:00 Justin wrote: *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/45 ------------------------------------------------------------------------ On 2014-07-10T21:44:44+00:00 Maurizio wrote: With kernel 3.15.3-200.fc20.i686+PAE it seems that the default in /proc/sys/kernel/keys/root_maxkeys is 10000 instead of 200; however this is just a workaround, since NFS key *should not* count against the root_maxkeys quota. By manually changing 10000 to a low value the problem appears again, thus showing that still the NFS keys count against the root quota. The NFS client runs on a Fedora 20, whereas the NFS server resides on a fedora-release-16-1, kernel 3.3.5-2.fc16.i686.PAE. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/49 ------------------------------------------------------------------------ On 2014-09-16T15:55:50+00:00 Dariusz wrote: @Maurizio Paolini: is the fact that the NFS keys *should not* count against the root_maxkeys quota documented anywhere? I was also expecting this to be outside the quote. I have made some research in the kernel code and here is what I was able to find: * the keyring is created with the KEY_ALLOC_NOT_IN_QUOTA flag (and the absense of Q flag in /proc/keys confirms that), however * individual keys are created in nfs_idmap_request_key: - request_key function is called, which - calls the internal (not listed in any exported headers) request_key_and_link function - request_key_and_link is passed the *KEY_ALLOC_IN_QUOTA* flag making it an explicit call to keep the key in the quota * nfsidmap executable from the nfs-utils package - uses a keyctl_instantiate function. The 4th parameter of this function is keyring id and in case of this tool is always 0. - I believe the control later enters kernel space in the keyctl_instantiate_key function via the syscall interface. - this keyring id is then mapped to an actual in-kernel keyring and the key being mapped (through the nfsidmap commandline) is linked to that keyring. Obviously, if 0 is always passed there it will never happen. On the other hand, patching this issue (locally) has not caused any changes in the quota behaviour. Summary: According to current implementation (and my understanding) current behavior is expected. I would be very interested any opinion on this. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/56 ------------------------------------------------------------------------ On 2014-11-13T15:56:17+00:00 Justin wrote: *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/83 ------------------------------------------------------------------------ On 2015-02-24T15:56:11+00:00 Josh wrote: David, can you look at comment #35 and comment #36 and weigh in? Are NFS keys to be counted towards the quota? Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/87 ------------------------------------------------------------------------ On 2015-02-24T17:28:25+00:00 Maurizio wrote: Just as an info. In a fedora 21 the default value for kernel.keys.maxkeys seems to have been increased to 1000000, with no entry in sysctl.conf; also the "maxbytes" has a very large default value. Manually lowering that quota still exposes the problem. I have no idea if the keys count against the root_maxkeys quota on purpose or not. [I changed the fedora release for this bug report to 21] Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/88 ------------------------------------------------------------------------ On 2015-11-04T15:50:40+00:00 Fedora wrote: This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/117 ------------------------------------------------------------------------ On 2015-12-02T02:41:34+00:00 Fedora wrote: Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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 Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. Reply at: https://bugs.launchpad.net/fedora/+bug/1124250/comments/118 ** Changed in: fedora Status: Unknown => Won't Fix ** Changed in: fedora Importance: Unknown => Critical ** Bug watch added: Red Hat Bugzilla #847084 https://bugzilla.redhat.com/show_bug.cgi?id=847084 ** Bug watch added: Red Hat Bugzilla #740024 https://bugzilla.redhat.com/show_bug.cgi?id=740024 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1124250 Title: Partially incorrect uid mapping with nfs4/idmapd/ldap-auth Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Released Status in linux source package in Utopic: Fix Released Status in nfs-utils package in Debian: Confirmed Status in Fedora: Won't Fix Bug description: [Impact] * This bug is likely to cause an incorrect UID/GID mapping for NFS shares in case of large numbers of differend UIDs/GIDs or in case of expired UID/GID mappings (stored as keys in the kernel). [Test Case] 1. Setup a nfs4 server exporting /home with a large number of different users and ldap-based authentication. 2. Mount the share on a ldap-connected client machine. 3. List the mounted /home directory. 4. Wait more than 10 minutes (the default key expiration time) and list it again with ls -l. Expected result - all directories are listed with correct UIDs/GIDs. Actual result - some of the directories may be listed with incorrect UID/GID of 4294967294. [Regression Potential] * This issue has been merged upstream in the 3.18 kernel and is also present in Debian's 3.16 kernel. [Other Info] * Original bug description: I'm running a nfs4 server exporting a directory /home (ext4,usrquota). This server is running Ubuntu 12.04 amd64(up-to-date). This directory is handling 662 homedirs for ldap authenticated users. /etc/exports is : /exports 192.168.0.0/24(rw,fsid=0,no_subtree_check) Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch. In /etc/default/nfs-common : NEED_IDMAPD=yes In /etc/default/nfs-kernel-server : RPCNFSDCOUNT=75 RPCMOUNTDOPTS=--manage-gids 2 Clients (rhel6 x86 & Ubuntu 12.04.2 i686) are mounting this nfs4 exported directory with no problems : When doing ls -l /home on this clients, I have : ... drwx------ 4 user100 oldusers 4096 sept. 21 2011 user100 drwx------ 4 user101 oldusers 4096 sept. 21 2011 user101 drwx------ 37 user102 oldusers 4096 oct. 1 19:06 user102 drwx------ 36 user103 users 4096 févr. 5 21:08 user103 drwx------ 36 user104 users 4096 févr. 8 14:03 user104 drwx------ 30 user105 users 4096 févr. 4 18:01 user105 drwx------ 28 user106 oldusers 4096 oct. 5 2011 user106 drwx------ 37 user107 oldusers 4096 janv. 8 14:52 user107 drwx------ 31 user108 users 4096 déc. 4 11:52 user108 drwx------ 4 user109 oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 user110 oldusers 4096 janv. 22 15:53 user109 drwx------ 31 user111 users 4096 janv. 29 12:03 user110 ... uid/gid mapping works fine, authldap works fine, ... All Clients running Ubuntu 12.10 i686 or Ubuntu 12.10 amd64 are experiencing the same problem : The config files are the same that used in ubuntu 12.04. Auth ldap is correctly configured, user can log in. This is the /etc/fstab entry for /home : 192.168.0.1:/ /home nfs rw,nfsvers=4 0 0 Important lines in /etc/idmapd.conf : domain=my-domain.org [Translation] Method=nsswitch In /etc/default/nfs-common : NEED_IDMAPD=yes /etc/nsswitch.conf is : passwd: files ldap group: files ldap shadow: files ldap When doing ls -l /home there is a strange problem : drwx------ 4 4294967294 oldusers 4096 sept. 21 2011 user100 drwx------ 4 user101 oldusers 4096 sept. 21 2011 user101 drwx------ 37 user102 oldusers 4096 oct. 1 19:06 user102 drwx------ 36 4294967294 users 4096 févr. 5 21:08 user103 drwx------ 36 4294967294 users 4096 févr. 8 14:03 user104 drwx------ 30 4294967294 users 4096 févr. 4 18:01 user105 drwx------ 28 4294967294 oldusers 4096 oct. 5 2011 user106 drwx------ 37 4294967294 oldusers 4096 janv. 8 14:52 user107 drwx------ 31 4294967294 users 4096 déc. 4 11:52 user108 drwx------ 4 user109 oldusers 4096 sept. 21 2011 user109 drwx--x--x 45 4294967294 oldusers 4096 janv. 22 15:53 user110 drwx------ 31 4294967294 users 4096 janv. 29 12:03 user111 for 571 homedirs (this number varies at each reboot)/662, the owner is the value 4294967294. For the 91 remaining homedirs, the owner is correct. The gidnumber is correctly mapped for all (only 5 differents values used for gidNumber). In /var/log/syslog, I can see : For example : user110 is mapped as 4294967294. but the command "id user110" returns : uid=31124(user110) gid=666(oldusers) groupes=666(oldusers) user110 logs in (auth ldap) from tty1. He runs "ls -l /home/user110/" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images Then, he runs "touch /home/user110/test" : drwxr-xr-x 8 4294967294 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 4294967294 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 4294967294 oldusers 4096 déc. 2 2011 Images drwxr-xr-x 2 4294967294 oldusers 0 févr. 13 16:01 test On the nfs server, If i do a ls -l in the same directory : drwxr-xr-x 8 user110 oldusers 4096 janv. 19 2012 Bureau drwxr-xr-x 3 user110 oldusers 4096 déc. 2 2011 Documents drwxr-xr-x 2 user110 oldusers 4096 déc. 2 2011 Images drwxr-xr-x 2 user110 oldusers 0 févr. 13 16:01 test I can see that the "test" file is owned by the correct user. I've tried without & with nscd, same results. I've tried using sssd, libnss-sss & pam_sss for ldap auth and having exactly the same results : In /var/log/syslog, I have : ... rpc.idmapd[561]: nss_getpwnam: name 'user...@my-domain.org' domain 'my-domain.org': resulting localname 'user109' rpc.idmapd[561]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 rpc.idmapd[561]: nfs4_name_to_uid: final return value is 0 rpc.idmapd[561]: Client 0: (user) name "user...@my-domain.org" -> id "55101" rpc.idmapd[561]: nfs4_name_to_uid: calling nsswitch->name_to_uid rpc.idmapd[561]: nss_getpwnam: name 'user...@my-domain.org' domain 'my-domain.org': resulting localname 'user102' rpc.idmapd[561]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 rpc.idmapd[561]: nfs4_name_to_uid: final return value is 0 rpc.idmapd[561]: Client 0: (user) name "user...@my-domain.org" -> id "55199" ... only for the correctly mapped entries. No warnings or errors (rate limit disabled in rsyslog.conf) and verbosity set to 5 in idmapd.conf. It seems that rpc.idmapd never does mapping for other entries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1124250/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
