Bug 876705

Summary: default maximum number of keys (200) too small for nfs4 uid-user mapping
Product: [Fedora] Fedora Reporter: Maurizio Paolini <paolini>
Component: kernelAssignee: David Howells <dhowells>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 21CC: anders.blomdell, bfields, carnil, dariusz.gadomski, dhowells, edgar.hoch, gansalmon, igeorgex, itamar, jansen, jonathan, jtrutwin, kernel-maint, lantw44, luca.giuzzi, madhu.chinakonda, mr.marcelo.barbosa, paolini, steved
Target Milestone: ---Flags: jwboyer: needinfo? (dhowells)
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1014573 (view as bug list) Environment:
Last Closed: 2015-12-01 21:41:15 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1014573, 1303877    

Description Maurizio Paolini 2012-11-14 13:52:45 EST
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.
Comment 1 Steve Dickson 2012-11-15 03:56:06 EST
*** Bug 847084 has been marked as a duplicate of this bug. ***
Comment 2 Steve Dickson 2012-11-15 04:01:16 EST
David,

Would it make sense to patch the kernel so the maxkeys/root_maxkeys are set to a more reasonable value?
Comment 3 Luca Giuzzi 2012-11-15 04:15:05 EST
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.
Comment 4 Maurizio Paolini 2013-02-03 17:09:14 EST
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?
Comment 5 Maurizio Paolini 2013-03-13 01:35:34 EDT
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
Comment 6 David Jansen 2013-04-10 04:27:53 EDT
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?
Comment 7 Anders Blomdell 2013-04-10 05:21:00 EDT
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
Comment 8 Maurizio Paolini 2013-04-10 08:30:42 EDT
(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.
Comment 9 Anders Blomdell 2013-04-10 09:03:36 EDT
This might be a starting point: http://comments.gmane.org/gmane.linux.nfs/51842
Comment 10 Luca Giuzzi 2013-04-10 18:10:22 EDT
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.
Comment 11 Maurizio Paolini 2013-04-15 09:38:17 EDT
(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.
Comment 12 David Jansen 2013-04-17 06:57:57 EDT
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.
Comment 13 Maurizio Paolini 2013-04-17 17:13:08 EDT
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
Comment 14 David Howells 2013-09-13 10:51:09 EDT
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.
Comment 15 David Howells 2013-10-02 07:04:03 EDT
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
Comment 16 Josh Boyer 2013-10-02 08:49:40 EDT
We're actually already carrying those patches in F20 and rawhide.
Comment 17 Justin M. Forbes 2013-10-18 17:02:10 EDT
*********** 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.
Comment 18 Justin M. Forbes 2014-01-03 17:05:29 EST
*********** 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.
Comment 19 Josh Boyer 2014-01-08 09:28:12 EST
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.
Comment 20 Maurizio Paolini 2014-01-08 10:45:45 EST
(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?
Comment 21 Josh Boyer 2014-01-08 12:03:40 EST
David, do you know why Maurizio is still seeing this given that we're carrying the updated keyring patches?
Comment 22 Maurizio Paolini 2014-01-08 12:53:57 EST
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
Comment 23 Edgar Hoch 2014-01-24 20:20:15 EST
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 .
Comment 24 Maurizio Paolini 2014-01-25 02:59:54 EST
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 .
Comment 25 Edgar Hoch 2014-01-25 03:46:28 EST
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.
Comment 26 Edgar Hoch 2014-01-25 03:53:12 EST
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.
Comment 27 Maurizio Paolini 2014-01-25 05:00:01 EST
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.
Comment 28 Anders Blomdell 2014-01-25 12:44:05 EST
Ah, using NIS/YP, try the *_tw_* workaround from https://bugzilla.redhat.com/show_bug.cgi?id=740024#c6
Comment 29 Maurizio Paolini 2014-01-25 15:01:00 EST
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
Comment 30 Edgar Hoch 2014-01-26 20:28:19 EST
(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.
Comment 31 Maurizio Paolini 2014-01-26 23:33:24 EST
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.
Comment 32 Justin M. Forbes 2014-02-24 08:52:57 EST
*********** 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.
Comment 33 Edgar Hoch 2014-02-24 11:49:14 EST
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).
Comment 34 Justin M. Forbes 2014-05-21 15:37:41 EDT
*********** 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.
Comment 35 Maurizio Paolini 2014-07-10 17:44:44 EDT
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.
Comment 36 Dariusz Gadomski 2014-09-16 11:55:50 EDT
@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.
Comment 37 Justin M. Forbes 2014-11-13 10:56:17 EST
*********** 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.
Comment 38 Josh Boyer 2015-02-24 10:56:11 EST
David, can you look at comment #35 and comment #36 and weigh in?  Are NFS keys to be counted towards the quota?
Comment 39 Maurizio Paolini 2015-02-24 12:28:25 EST
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]
Comment 40 Fedora End Of Life 2015-11-04 10:50:40 EST
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.
Comment 41 Fedora End Of Life 2015-12-01 21:41:34 EST
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.