This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 719776

Summary: nfs-utils-1.2.4-0 prevents NFSv4 mounts with sec=krb5p
Product: [Fedora] Fedora Reporter: Anthony Messina <amessina>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 15CC: bfields, jlayton, k.georgiou, kwc, steved, thieme.reis
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: nfs-utils-1.2.4-1.fc15 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-02 22:27:46 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Anthony Messina 2011-07-07 20:13:16 EDT
After upgrading from nfs-utils-1.2.3-11.fc15.x86_64 to nfs-utils-1.2.4-0.fc15.x86_64 on my NFSv4 servers and clients, my server logs are littered with errors such as the following and the clients are unable to mount any of the exported file systems:

Jul  7 17:35:33 chicago rpc.svcgssd[1267]: libnfsidmap: using domain: messinet.com
Jul  7 17:35:33 chicago rpc.svcgssd[1267]: libnfsidmap: Realms list: 'MESSINET.COM' 
Jul  7 17:35:33 chicago rpc.svcgssd[1267]: libnfsidmap: loaded plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch
Jul  7 17:35:33 chicago rpc.svcgssd[1267]: entering poll
Jul  7 17:36:10 chicago rpc.svcgssd[1267]: leaving poll
Jul  7 17:36:10 chicago rpc.svcgssd[1267]: handling null request
Jul  7 17:36:10 chicago rpc.svcgssd[1267]: WARNING: gss_accept_sec_context failed
Jul  7 17:36:10 chicago rpc.svcgssd[1267]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - No supported encryption types (config file error?)
Jul  7 17:36:10 chicago rpc.svcgssd[1267]: sending null reply
Jul  7 17:36:10 chicago rpc.svcgssd[1267]: finished handling null request

In addition, with the upgraded version, the server also reports tons of SELinux AVCs (in permissive and enforcing mode):
SELinux is preventing /usr/sbin/rpc.svcgssd from search access on the directory /proc/fs/nfsd

Downgrading to nfs-utils-1.2.3-11.fc15.x86_64 on the server (even with the clients keeping nfs-utils-1.2.4-0.fc15.x86_64) resolves all of the above issues.

I realize the upgrade was to fix:
Bug #716949
http://marc.info/?l=linux-nfs&m=130875695821953&w=2

Here is /etc/exports:
/export                 *.messinet.com(fsid=0,sec=krb5p)
/export/home            *.messinet.com(rw,nohide,sec=krb5p)
Comment 1 J. Bruce Fields 2011-07-07 20:44:25 EDT
That update brings in the code that reads fs/nfsd/supported_krb5_enctypes.  So we probably just need a fix to the selinux policy to allow that .  (Do your problems all go away on "setenforce 0"?)

But svcgssd could be more helpful here: maybe it should fall back on old behavior on failure to open supported_krb5_enctypes, instead of failing completely?
Comment 2 Anthony Messina 2011-07-07 20:51:23 EDT
(In reply to comment #1)
> That update brings in the code that reads fs/nfsd/supported_krb5_enctypes.  So
> we probably just need a fix to the selinux policy to allow that .  (Do your
> problems all go away on "setenforce 0"?)

Unfortunately, even with setenforce 0, the exported filesystems would not mount.  If it were just the SELinux issue, I would have created a temporary fix (audit2allow).

> But svcgssd could be more helpful here: maybe it should fall back on old
> behavior on failure to open supported_krb5_enctypes, instead of failing
> completely?

Any advice on the non-SELinux component?
Comment 3 Anthony Messina 2011-07-07 21:46:50 EDT
I was able to reproduce this problem on a freshly installed virtual system (i686).  Also, downgrading nfs-utils on the virtual system as described above resolved the issue.
Comment 4 J. Bruce Fields 2011-07-07 22:04:59 EDT
Are the same errors as above logged in the case SELinux is off, or is the log output different?
Comment 5 Anthony Messina 2011-07-07 22:12:53 EDT
The SELinux errors are identical in permissive and enforcing mode.  Running SELinux in permissive mode, however does not fix the issue of not being able to mount the filesystem.  On the virtual install, I had SELinux disabled for the entire testing process (in fact, I have SELinux off on that vhost completely).
Comment 6 J. Bruce Fields 2011-07-07 23:17:06 EDT
"The SELinux errors are identical in permissive and enforcing mode."

Right, that's expected, I wondered about the other log output; "No supported encryption types" seemed like it could be a consequence of an SELinux denial.  It'd be interesting to see a version of the above log fragment for the non-enforcing case, if it's different.
Comment 7 Kevin Coffman 2011-07-07 23:41:22 EDT
Can you tell me what, if any, options you use when starting svcgssd?  Are there any more hints if "-vvv" is specified?
Comment 8 Anthony Messina 2011-07-08 00:01:17 EDT
Thank you gentlemen for your quick feedback.  I'll need to wait until tomorrow evening, however, to get you more detailed logs.  I'll be sure to add -vvv to the rpc.svcgssd options.
Comment 9 Kevin Coffman 2011-07-08 10:00:34 EDT
Anthony,
It might be helpful to also get a look at the output of a successful mount with the older version of svcgssd running with -vvv to compare vs. the new version.

The output of running "sudo klist -ekt" would also be helpful.

Bruce,
The new code should already default the encryption types to DES if the proc file cannot be read.  I'm wondering if that might be the problem.  (AES is currently being used successfully and DES is disabled.)  This might be the case with newer installations that never had to limit things to DES.
Comment 10 Anthony Messina 2011-07-08 21:41:43 EDT
(In reply to comment #9)
> Anthony,
> It might be helpful to also get a look at the output of a successful mount with
> the older version of svcgssd running with -vvv to compare vs. the new version.
> 
> The output of running "sudo klist -ekt" would also be helpful.

# klist -ekt
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   2 07/07/11 20:09:15 host/f15-i686.virt.messinet.com@MESSINET.COM (aes256-cts-hmac-sha1-96) 
   2 07/07/11 20:09:15 host/f15-i686.virt.messinet.com@MESSINET.COM (aes128-cts-hmac-sha1-96) 
   2 07/07/11 20:09:16 host/f15-i686.virt.messinet.com@MESSINET.COM (des3-cbc-sha1) 
   2 07/07/11 20:09:16 host/f15-i686.virt.messinet.com@MESSINET.COM (arcfour-hmac) 
   2 07/07/11 20:09:19 nfs/f15-i686.virt.messinet.com@MESSINET.COM (aes256-cts-hmac-sha1-96) 
   2 07/07/11 20:09:20 nfs/f15-i686.virt.messinet.com@MESSINET.COM (aes128-cts-hmac-sha1-96) 
   2 07/07/11 20:09:20 nfs/f15-i686.virt.messinet.com@MESSINET.COM (des3-cbc-sha1) 
   2 07/07/11 20:09:20 nfs/f15-i686.virt.messinet.com@MESSINET.COM (arcfour-hmac)


> Bruce,
> The new code should already default the encryption types to DES if the proc
> file cannot be read.  I'm wondering if that might be the problem.  (AES is
> currently being used successfully and DES is disabled.)  This might be the case
> with newer installations that never had to limit things to DES.
Comment 11 Anthony Messina 2011-07-08 21:43:01 EDT
(In reply to comment #6)
> "The SELinux errors are identical in permissive and enforcing mode."
> 
> Right, that's expected, I wondered about the other log output; "No supported
> encryption types" seemed like it could be a consequence of an SELinux denial. 
> It'd be interesting to see a version of the above log fragment for the
> non-enforcing case, if it's different.

I've replicated this setup on a vhost so I can keep my other dependent systems up and running.

Below is the output from rpc.svcgssd -vvv in non-enforcing (permissive) mode:
Jul  8 20:37:37 f15-i686 rpc.svcgssd[1507]: libnfsidmap: using domain: messinet.com
Jul  8 20:37:37 f15-i686 rpc.svcgssd[1507]: libnfsidmap: Realms list: 'MESSINET.COM' 
Jul  8 20:37:37 f15-i686 rpc.svcgssd[1507]: libnfsidmap: loaded plugin /lib/libnfsidmap/nsswitch.so for method nsswitch
Jul  8 20:37:37 f15-i686 rpc.svcgssd[1507]: entering poll
Jul  8 20:37:37 f15-i686 kernel: [ 2755.585919] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Jul  8 20:37:37 f15-i686 kernel: [ 2755.585949] NFSD: starting 90-second grace period
Jul  8 20:37:37 f15-i686 rpc.mountd[1526]: Version 1.2.4 starting
Jul  8 20:37:37 f15-i686 rpc.idmapd[1140]: ReOpening /proc/net/rpc/nfs4.nametoid/channel
Jul  8 20:37:37 f15-i686 rpc.idmapd[1140]: ReOpening /proc/net/rpc/nfs4.idtoname/channel
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: leaving poll
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: handling null request
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: WARNING: gss_accept_sec_context failed
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - Encryption type not permitted
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: sending null reply
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: writing message: \x \x6082029006092a864886f71201020201006e82027f3082027ba003020105a10302010ea20703050020000000a382017b6182017730820173a003020105a10e1b0c4d455353494e45542e434f4da22c302aa003020103a12330211b036e66731b1a6631352d693638362e766972742e6d657373696e65742e636f6da382012c30820128a003020112a103020102a282011a0482011669c63bcf118f4e51942594589268202f4aa86083d79f7e8b7ce813e5d0dfafcf30bc96ef5aced0e18d6d59edc3043017cd1b61f0d1571dc134566a9e085f5c6bdaba36975b51e356c559ecfc933d4245b53800d7090bb2901004c7b15d6f1666f192a00a2260dce6b29399a8b2cdae2cc2804290a5945f982e349a977dcd58c6a9f323766afc951a9050b25d48f55dba673f9cfc26cac0fe8da6e61e2e953993444caa14748ecdf314fc444f79f8146b80c2feefca94a634d2b76bd493d3b617e9cba78b9f64fe3e25d125255d784ad0946371bde9ecc5be4a0ce90cd713013820934653ab34ce222e0a2f5db619d272afa0e6a47104ca60128a321cbde08ebf7fa74f540274bd5135897fa5d00b3ee9f8a1e788fd6ea481e63081e3a003020112a281db0481d8a360c12294ab9359550a0baf688d232a0897b8004d9c597bb73a0d4f9c817dad1cd728e4a50c00d111825f9d902ce686ebbf4c9ed515fc159f82dd6b0815ff0b9f9f0a062c3a055957b2a26e2c536ba8dab0773f3374996e29a3d77342d808a866dcad0a1c070509c43b0d3d7b704d0f0eae9efe3eb004557c4a3170c34b9c718f49db2ceacd86c4b86aec25e3c77f9ea336765da2778e0552059218c7b4556c2b3b639da11e472aadf6b5619696fb1c359a5672636f8a7f5450b26f400075866fc334f6c2ea9e4a036dedadb0a2165d0c96a40f4fdfdb39 1310175693 851968 2529639148 \x \x 
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: finished handling null request
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: entering poll
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: leaving poll
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: handling null request
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: WARNING: gss_accept_sec_context failed
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - Encryption type not permitted
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: sending null reply
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: writing message: \x \x6082029006092a864886f71201020201006e82027f3082027ba003020105a10302010ea20703050020000000a382017b6182017730820173a003020105a10e1b0c4d455353494e45542e434f4da22c302aa003020103a12330211b036e66731b1a6631352d693638362e766972742e6d657373696e65742e636f6da382012c30820128a003020112a103020102a282011a0482011669c63bcf118f4e51942594589268202f4aa86083d79f7e8b7ce813e5d0dfafcf30bc96ef5aced0e18d6d59edc3043017cd1b61f0d1571dc134566a9e085f5c6bdaba36975b51e356c559ecfc933d4245b53800d7090bb2901004c7b15d6f1666f192a00a2260dce6b29399a8b2cdae2cc2804290a5945f982e349a977dcd58c6a9f323766afc951a9050b25d48f55dba673f9cfc26cac0fe8da6e61e2e953993444caa14748ecdf314fc444f79f8146b80c2feefca94a634d2b76bd493d3b617e9cba78b9f64fe3e25d125255d784ad0946371bde9ecc5be4a0ce90cd713013820934653ab34ce222e0a2f5db619d272afa0e6a47104ca60128a321cbde08ebf7fa74f540274bd5135897fa5d00b3ee9f8a1e788fd6ea481e63081e3a003020112a281db0481d8575f043e164cc0fd2e25a65b8a26d1f87a84cda5bdc89e37240374bae242783ece23e001e0e0a8904e4cb34be4ba63a3fea57ec10b5a3428165ed019563e5fd323b799e4479a1752a24affa31c54854376c868ba176069fc6eafa83103689069f770e0c87e79aad18c1fc51ef6086014b8430fa7c2bd40f98ffcfdd39b9bdd71710a625c10ed31011ad50b5137b023985b7bc8c1984b629802121faa115a285ed477ebc4fbc5229c204ce0d0cc3352d4ebc7b07a09a5e668d057a461383fd9b4953b48d42ec5ee302d9fbc91d7ca292975ae2ef1dd020cc1 1310175693 851968 2529639148 \x \x 
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: finished handling null request
Jul  8 20:40:33 f15-i686 rpc.svcgssd[1507]: entering poll
Comment 12 Anthony Messina 2011-07-08 21:44:52 EDT
(In reply to comment #1)
> That update brings in the code that reads fs/nfsd/supported_krb5_enctypes.  So
> we probably just need a fix to the selinux policy to allow that .  (Do your
> problems all go away on "setenforce 0"?)
> 
> But svcgssd could be more helpful here: maybe it should fall back on old
> behavior on failure to open supported_krb5_enctypes, instead of failing
> completely?

My server system doesn't seem to have that file 'supported_krb5_enctypes' which may be the problem:

[root@f15-i686 nfsd]# ls -l /proc/fs/nfsd
total 0
-r--r--r--. 1 root root 0 Jul  8 19:52 export_features
-r--r--r--. 1 root root 0 Jul  8 19:52 exports
-rw-------. 1 root root 0 Jul  8 19:52 filehandle
-rw-r--r--. 1 root root 0 Jul  8 19:52 max_block_size
-rw-------. 1 root root 0 Jul  8 19:52 nfsv4gracetime
-rw-------. 1 root root 0 Jul  8 19:52 nfsv4leasetime
-rw-------. 1 root root 0 Jul  8 19:52 nfsv4recoverydir
-r--r--r--. 1 root root 0 Jul  8 19:52 pool_stats
-rw-------. 1 root root 0 Jul  8 19:52 pool_threads
-rw-r--r--. 1 root root 0 Jul  8 19:52 portlist
-rw-------. 1 root root 0 Jul  8 19:52 threads
-rw-------. 1 root root 0 Jul  8 19:52 unlock_filesystem
-rw-------. 1 root root 0 Jul  8 19:52 unlock_ip
-rw-------. 1 root root 0 Jul  8 19:52 versions
Comment 13 Anthony Messina 2011-07-08 21:47:25 EDT
(In reply to comment #9)
> Anthony,
> It might be helpful to also get a look at the output of a successful mount with
> the older version of svcgssd running with -vvv to compare vs. the new version.


The following output is from my production system which I have downgraded to the previous version of nfs-utils.  Aside from the hostname differences, compare with comment #11):

Jul  8 20:46:05 chicago rpc.svcgssd[22563]: leaving poll
Jul  8 20:46:05 chicago rpc.svcgssd[22563]: handling null request
Jul  8 20:46:05 chicago rpc.svcgssd[22563]: sname = nfs/ws1.mobile.messinet.com@MESSINET.COM
Jul  8 20:46:05 chicago rpc.svcgssd[22563]: DEBUG: serialize_krb5_ctx: lucid version!
Jul  8 20:46:05 chicago rpc.svcgssd[22563]: prepare_krb5_rfc4121_buffer: protocol 1
Jul  8 20:46:05 chicago rpc.svcgssd[22563]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32
Jul  8 20:46:05 chicago rpc.svcgssd[22563]: doing downcall
Jul  8 20:46:05 chicago rpc.svcgssd[22563]: mech: krb5, hndl len: 4, ctx len 52, timeout: 1310262035 (86070 from now), clnt: nfs@ws1.mobile.messinet.com, uid: -1, gid: -1, num aux grps: 0:
Jul  8 20:46:05 chicago rpc.svcgssd[22563]: sending null reply
Jul  8 20:46:05 chicago rpc.svcgssd[22563]: writing message: \x \x6082029706092a864886f71201020201006e82028630820282a003020105a10302010ea20703050020000000a38201826182017e3082017aa003020105a10e1b0c4d455353494e45542e434f4da21e301ca003020103a11530131b036e66731b0c6d657373696e65742e636f6da38201413082013da003020112a103020102a282012f0482012b23f440e7b31975a2446873093dddb164dca0887628d33610b5762554d03bea076f2ed286419a50e83cbe52f93abdda7854f78d34a44eae21d7af061b4446cd5688720e166400e8fe1f83461142614a22404003732460aa43ee71cee430b435c22a7154b354eaa1b691a7e8f65e7160e9523a7b5aa7b6e9b2e38ccc70c4f47e15e7051ee5030eb258c6648b1830a841ceb095b6b270d4d33ed094c8ce8dc5cdcca4bab5da682bb1be16930063b569a193bad44fe738e406cd2cb69dacfaeb14de51d598f04ef7759d10afb4833937a56ef5f7f319693f9a3152a12834ea4b2769f127796b529b0fb64cb51cff583e3781fd9b61c677d39a914aa8a58dfd78ff05eac056ae93f9ae4a1ee3740fac2d7252ab209046082cc2ed52d0c7b341ad7086521930ac9d53cf7af6b90da481e63081e3a003020112a281db0481d8726b20b0bb71db2e1197c59106b72324fc794a2c9f2b31941215cd0bc5fadf9e657e163b490c096b690407812f17ebf96319bf4c89cf584bb9b1b355fd25145ec64c7b13a78a5cd4aeff1ecfd7d961060aee41e32c5f39c1911685bb585b1974e96613c003ce6782c1e28d9cea5192981f852f6b9a5cdf2315ac33718ef2e3fab95913f61718e7455ed3e3ed73b8fd595d69fadde84bea2680b1cafa360948a8dd31aaa77e8bd719b1b0352d3d2e4d4610714337cca12d8efd1c077ef9cd982a61f624a135edaf7f01ac5d3ceba74f9fd739d47c1eea2209 1310176025 0 0 \x05000000 \x60819906092a864886f71201020202006f8189308186a003020105a10302010fa27a3078a003020112a271046fc5d974ff9b9f9d76a0ed977b23aeed7f85832a329260a8cedc25df1ebbdc3a5668ff76ba0de4976068d7b5a83cbf4864a2b584e69397470301f0ec3001fa1491ab0c030c40efe1dd666cc5395ceebcdfc9606f8f49779d81d4dde42d9c236a07b5ceade2bf15221aad236b267aeafa 
Jul  8 20:46:05 chicago rpc.svcgssd[22563]: finished handling null request
Jul  8 20:46:05 chicago rpc.svcgssd[22563]: entering poll
Comment 14 Kevin Coffman 2011-07-08 22:06:30 EDT
OK, thanks.  Your keytab doesn't have a DES key.  Is your KDC a Windows AD, MIT, or Heimdal?

Since we are unable to read the kernel supported enctypes, we assume only DES is supported by the kernel and limit the negotiation to DES.  I assume that you do not have "allow_weak_crypto = true" in your /etc/krb5.conf file.

I'll have to think about what to do in this case.  Perhaps if we can't read the kernel's supported enctypes file we should just not limit the negotiation.  This will result in errors when the kernel truly only supports DES and the Kerberos library asserts a sub-key of a different enctype.
Comment 15 Anthony Messina 2011-07-08 22:15:43 EDT
(In reply to comment #14)
> OK, thanks.  Your keytab doesn't have a DES key.  Is your KDC a Windows AD,
> MIT, or Heimdal?

MIT, stock setup from Fedora.

> Since we are unable to read the kernel supported enctypes, we assume only DES
> is supported by the kernel and limit the negotiation to DES.  I assume that you
> do not have "allow_weak_crypto = true" in your /etc/krb5.conf file.

I know about this workaround.  I had to use it for a bit during F14's reign, but after it was "fixed", I've removed all of those lines from clients and servers and re-issued keytabs with the standard enctypes exported as listed above.

> I'll have to think about what to do in this case.  Perhaps if we can't read the
> kernel's supported enctypes file we should just not limit the negotiation. 
> This will result in errors when the kernel truly only supports DES and the
> Kerberos library asserts a sub-key of a different enctype.

Why do you think I am missing the /proc/fs/nfsd/supported_krb5_enctypes file?
Comment 16 Anthony Messina 2011-07-08 22:20:53 EDT
Just a quick search, but does the 2.6.38.8-32.fc15 kernel have this issue:
https://patchwork.kernel.org/patch/723971/
Comment 17 Kevin Coffman 2011-07-08 22:30:11 EDT
I believe the patch to add the /proc/fs/nfsd/supported_krb5_enctypes file went into 2.6.39.  I don't know whether it might have been pulled into earlier Redhat kernels.
Comment 18 Anthony Messina 2011-07-08 23:25:30 EDT
Ok, I just looked at the sources from fedpkg.  The 2.6.38 Fedora Kernels do not include any patch for "supported_krb5_enctypes".  The f15-2.6.39 git branch sources contain the original kernel patch for supported_krb5_enctypes, but that would only lead to the problem here: https://patchwork.kernel.org/patch/723971/ where it would not work as a loadable module.

What happens now?  Does the 2.6.38 Fedora kernel need the patch to allow it to work with secure nfs and the now "stable" nf-utils.
Comment 19 Anthony Messina 2011-07-08 23:45:23 EDT
It looks like Fedora 15's 2.6.38 kernels might need:
http://www.mail-archive.com/stable@linux.kernel.org/msg13158.html in order to work with the now released nfs-utils and kerberos/gssapi security.
Comment 20 J. Bruce Fields 2011-07-10 16:31:21 EDT
"Does the 2.6.38 Fedora kernel need the patch to allow it to work with secure nfs and the now "stable" nf-utils."

No, nfs-utils must be able to deal with older kernels--we need to make sure it falls back on previous behavior as a default.
Comment 21 Anthony Messina 2011-07-11 00:14:09 EDT
(In reply to comment #20)
> "Does the 2.6.38 Fedora kernel need the patch to allow it to work with secure
> nfs and the now "stable" nf-utils."
> 
> No, nfs-utils must be able to deal with older kernels--we need to make sure it
> falls back on previous behavior as a default.

Ok.  Thanks for the update.  I hope this doesn't mean I'll need to go *back* to allow_weak_crypto and re issue all those tickets.  I appreciate the help on this.
Comment 22 Kevin Coffman 2011-07-11 09:33:15 EDT
(In reply to comment #20)
> "Does the 2.6.38 Fedora kernel need the patch to allow it to work with secure
> nfs and the now "stable" nf-utils."
> 
> No, nfs-utils must be able to deal with older kernels--we need to make sure it
> falls back on previous behavior as a default.

If the supported_krb5_enctypes file cannot be read, the default enctypes to use will need to be kernel-specific.  2.6.37 (need to double-check that) and later should default to "all" of them, prior kernels should default to DES only.  I'll attempt to do a patch this Wednesday.  If someone wants to beat me to it, I won't be offended.
Comment 23 J. Bruce Fields 2011-07-11 09:52:35 EDT
I think I'd prefer to make svcgssd_limit_krb5_enctypes() a no-op in the case where we can't find supported_krb5_enctypes, as you suggest in comment 14.  That's not the ideal behavior, but it's at least guaranteed to keep existing systems working, since it's what we've always done before (if I understand correctly).
Comment 24 Kevin Coffman 2011-07-11 10:04:11 EDT
(In reply to comment #23)
> I think I'd prefer to make svcgssd_limit_krb5_enctypes() a no-op in the case
> where we can't find supported_krb5_enctypes, as you suggest in comment 14. 
> That's not the ideal behavior, but it's at least guaranteed to keep existing
> systems working, since it's what we've always done before (if I understand
> correctly).

The reason this code was added was to fix the case where AES subkeys are asserted by Kerberos, but the kernel only supports DES.  If we were going to do as you suggest, we could probably just remove these changes.  I think a kernel version check is req'd.
Comment 25 Alexandre Thieme Reis 2011-07-12 18:34:08 EDT
After upgrade kerberos (version 1.9.1) and nfs-utils ( version 1.2.4), nfs shares not mount anymore.


client mount:
tango.atr.eti.br/home   /home   nfs4   sec=krb5   0   0

Kernel version:  2.6.38.8-35 and fc15 with all updates (12/07/2011)

/var/log/messages: 
Jul 12 19:23:17 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - No supported encryption types (config file error?)
Jul 12 19:23:18 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - No supported encryption types (config file error?)
Jul 12 19:23:18 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - No supported encryption types (config file error?)
Jul 12 19:23:19 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - No supported encryption types (config file error?)

"allow_weak_crypto = true" only change error message:

Jul 12 19:27:24 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - Encryption type not permitted
Jul 12 19:27:24 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - Encryption type not permitted
Jul 12 19:27:25 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - Encryption type not permitted
Jul 12 19:27:26 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - Encryption type not permitted

What i do? Users are furious!
Comment 26 Anthony Messina 2011-07-14 19:46:34 EDT
(In reply to comment #25)
> After upgrade kerberos (version 1.9.1) and nfs-utils ( version 1.2.4), nfs
> shares not mount anymore.
> 
> What i do? Users are furious!

You could downgrade to nfs-utils-1.2.3-11.fc15 while these gentlemen are working on the fix.  That is what I have done.
Comment 27 Alexandre Thieme Reis 2011-07-14 20:35:26 EDT
I'm using nfs version 3
Comment 28 Anthony Messina 2011-07-14 22:12:27 EDT
Really(In reply to comment #25)
> After upgrade kerberos (version 1.9.1) and nfs-utils ( version 1.2.4), nfs
> shares not mount anymore.
> 
> 
> client mount:
> tango.atr.eti.br/home   /home   nfs4   sec=krb5   0   0

It looks like NFSv4 to me.........^^^^.
Comment 29 Anthony Messina 2011-07-14 22:59:30 EDT
Kevin, I can confirm your patch works: http://article.gmane.org/gmane.linux.nfs/41981

I have applied your patch and created RPMs which I will use until this hits the Fedora repos: http://messinet.com/koji/taskinfo?taskID=2517

Thank you very much for your work on this.
Comment 30 Anthony Messina 2011-07-14 23:05:39 EDT
I've submitted the SELinux portion of the issue bug #722368
Comment 31 Fedora Update System 2011-07-25 13:51:18 EDT
nfs-utils-1.2.4-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/nfs-utils-1.2.4-1.fc15
Comment 32 Fedora Update System 2011-07-25 23:45:51 EDT
Package nfs-utils-1.2.4-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.4-1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/nfs-utils-1.2.4-1.fc15
then log in and leave karma (feedback).
Comment 33 Fedora Update System 2011-08-02 22:27:39 EDT
nfs-utils-1.2.4-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.