NFSv4 + Kerberos + users
Kevin Coffman
kwc at citi.umich.edu
Fri Jun 22 09:54:28 EDT 2007
On 6/22/07, Zoltan Menyhart <Zoltan.Menyhart at bull.net> wrote:
> Kevin Coffman wrote:
>
> > It might be interesting to see what messages svcgssd produced on the
> > server for this error.
>
> I re-created the problem:
>
> # su - linux
> $ kinit
> Password for linux at FREC.BULL.FR:
>
> $ klist
> Ticket cache: FILE:/tmp/krb5cc_500
> Default principal: linux at FREC.BULL.FR
>
> Valid starting Expires Service principal
> 06/22/07 10:41:29 06/23/07 10:41:26 krbtgt/FREC.BULL.FR at FREC.BULL.FR
>
> Kerberos 4 ticket cache: /tmp/tkt500
> klist: You have no tickets cached
>
> $ logout
> # kinit
> Password for root at FREC.BULL.FR:
>
> # klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: root at FREC.BULL.FR
>
> Valid starting Expires Service principal
> 06/22/07 10:42:47 06/23/07 10:42:44 krbtgt/FREC.BULL.FR at FREC.BULL.FR
>
> Kerberos 4 ticket cache: /tmp/tkt0
> klist: You have no tickets cached
>
> # mount lucy2_10g:/
> mount.nfs4: Permission denied
>
> # klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: root at FREC.BULL.FR
>
> Valid starting Expires Service principal
> 06/22/07 10:42:47 06/23/07 10:42:44 krbtgt/FREC.BULL.FR at FREC.BULL.FR
> 06/22/07 10:42:53 06/23/07 10:42:44 nfs/lucy2_10g.frec.bull.fr at FREC.BULL.FR
>
> Kerberos 4 ticket cache: /tmp/tkt0
> klist: You have no tickets cached
>
>
> Repeating the mount command re-creates the error.
>
> Here is what gssd (running in the foreground) says:
>
> handling krb5 upcall
> getting credentials for client with uid 0 for server lucy2_10g.frec.bull.fr
> CC file 'krb5cc_500' being considered
> '/tmp/krb5cc_500' owned by 500, not 0
> CC file 'krb5cc_machine_FREC.BULL.FR' being considered
> CC file 'krb5cc_machine_FREC.BULL.FR' matches owner check and has mtime of 1181136512
> CC file 'krb5cc_0' being considered
> CC file 'krb5cc_0' matches owner check and has mtime of 1182501767
> CC file 'krb5cc_0' is our current best match with mtime of 1182501767
> using FILE:/tmp/krb5cc_0 as credentials cache for client with uid 0 for server lucy2_10g.frec.bull.fr
> using environment variable to select krb5 ccache FILE:/tmp/krb5cc_0
> creating context using fsuid 0 (save_uid 0)
> creating tcp client for server lucy2_10g.frec.bull.fr
> creating context with server nfs at lucy2_10g.frec.bull.fr
> WARNING: Failed to create krb5 context for user with uid 0 for server lucy2_10g.frec.bull.fr
> WARNING: Failed to create krb5 context for user with uid 0 for server lucy2_10g.frec.bull.fr
> doing error downcall
>
>
> Here is what svcgssd says (from the /var/log/messages, the prefix
> "Jun 22 10:42:53 lucy2 rpc.svcgssd[19713]:" removed):
>
> leaving poll
> handling null request
> readline: read 940 chars into buffer of size 2048: \x \x608201cf06092a864886f71201020201006e8201be308201baa003020105a10302010ea20703050020000000a381fb6181f83081f5a003020105a10e1b0c465245432e42554c4c2e4652a2283026a003020103a11f301d1b036e66731b166c756379325f3130672e667265632e62756c6c2e6672a381b33081b0a003020101a103020105a281a30481a0d5bfdb65a58da872809729909a7c0d0a8b4b5d39b116fad46d8a7b34c04c1460673fd1bf4363510424ff2291880e2d8da2cab85dde370e206570cac7fd9cc17ef5ee567e932ec10282cf15448e78e1abb92...
> in_handle:
> length 0
>
> in_tok:
> length 467
>
> 0000: 6082 01cf 0609 2a86 4886 f712 0102 0201 `.....*.H.......
> 0010: 006e 8201 be30 8201 baa0 0302 0105 a103 .n...0..........
> 0020: 0201 0ea2 0703 0500 2000 0000 a381 fb61 ........ ......a
> 0030: 81f8 3081 f5a0 0302 0105 a10e 1b0c 4652 ..0...........FR
> 0040: 4543 2e42 554c 4c2e 4652 a228 3026 a003 EC.BULL.FR.(0&..
> 0050: 0201 03a1 1f30 1d1b 036e 6673 1b16 6c75 .....0...nfs..lu
> 0060: 6379 325f 3130 672e 6672 6563 2e62 756c cy2_10g.frec.bul
> 0070: 6c2e 6672 a381 b330 81b0 a003 0201 01a1 l.fr...0........
> 0080: 0302 0105 a281 a304 81a0 d5bf db65 a58d .............e..
> 0090: a872 8097 2990 9a7c 0d0a 8b4b 5d39 b116 .r..)..|...K]9..
> 00a0: fad4 6d8a 7b34 c04c 1460 673f d1bf 4363 ..m.{4.L.`g?..Cc
> 00b0: 5104 24ff 2291 880e 2d8d a2ca b85d de37 Q.$."...-....].7
> 00c0: 0e20 6570 cac7 fd9c c17e f5ee 567e 932e . ep.....~..V~..
> 00d0: c102 82cf 1544 8e78 e1ab b921 38b7 657b .....D.x...!8.e{
> 00e0: d015 6480 4864 36d5 a7a8 3e50 2120 5df8 ..d.Hd6...>P! ].
> 00f0: 1dad 12ab 9c2b dab8 ae84 5283 d77a 55d4 .....+....R..zU.
> 0100: 3cb2 8274 78f9 cabd 8d5b a752 2857 5bea <..tx....[.R(W[.
> 0110: 417a 6b0b 283d a4c3 c625 c067 6a32 25e7 Azk.(=...%.gj2%.
> 0120: 0967 ed56 88a9 aab1 e6de a481 a630 81a3 .g.V.........0..
> 0130: a003 0201 01a2 819b 0481 985e 1327 468d ...........^.'F.
> 0140: a1f6 c2ae 10af 0bf5 e772 f858 c1ec 4ba8 .........r.X..K.
> 0150: 0c78 fbf0 0410 ff0d 6d2c cb29 7e55 8175 .x......m,.)~U.u
> 0160: e76e b52a 6cae 1264 84d5 ea64 0449 2b38 .n.*l..d...d.I+8
> 0170: 9c8d 3372 aeaa 517e ec14 6a5a 761d 796a ..3r..Q~..jZv.yj
> 0180: 2843 34ae 7c6e 57d1 f04f 1427 432f 70cf (C4.|nW..O.'C/p.
> 0190: b2e0 2d0e 22a7 03f9 dd65 2fa5 86d7 67f1 ..-."....e/...g.
> 01a0: 919d 4fa5 19ce f50e 9c6e 409b ce5a 572d ..O......n at ..ZW-
> 01b0: 242c 6097 66a9 39d0 ece6 3d8e 9239 63ab $,`.f.9...=..9c.
> 01c0: d575 83fa 2e31 d38e 0a0e 61f2 aca1 bc8f .u...1....a.....
> 01d0: 2350 b5 #P.
> sname = root at FREC.BULL.FR
> nss_getpwnam: name 'root at FREC.BULL.FR' domain '(null)': resulting localname 'root'
> nss_getpwnam: name 'root at FREC.BULL.FR' domain '(null)': resulting localname 'root'
> serialize_krb5_ctx: serializing keys with enctype 4 and length 8
> doing downcall
> \x02000000 2147483647 0 0 7 0 1 2 3 4 6 10 krb5 \x000000000000000000000000000000000000000000000000000000000000000004dd7c46ace4ea33090000002a864886f7120102020400000008000000203707431a52a22f0400000008000000d0c7f7b3eaa252df
> sending null reply
> writing message: \x \x608201cf06092a864886f71201020201006e8201be308201baa003020105a10302010ea20703050020000000a381fb6181f83081f5a003020105a10e1b0c465245432e42554c4c2e4652a2283026a003020103a11f301d1b036e66731b166c756379325f3130672e667265632e62756c6c2e6672a381b33081b0a003020101a103020105a281a30481a0d5bfdb65a58da872809729909a7c0d0a8b4b5d39b116fad46d8a7b34c04c1460673fd1bf4363510424ff2291880e2d8da2cab85dde370e206570cac7fd9cc17ef5ee567e932ec10282cf15448e78e1abb92138b7657bd0156480486436d5a7a83e502...
> finished handling null request
> entering poll
>
>
> The /etc/fstab includes:
>
> lucy2_10g:/ /imports nfs4 sec=krb5,rw,nodev,sync,proto=tcp,retry=10,rsize=32768,wsize=32768,hard,intr 0 0
>
> The /etc/exports:
>
> /export gss/krb5(sync,rw,fsid=0,insecure,no_subtree_check,anonuid=65534,anongid=65534)
> /export/sdb6 gss/krb5(sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534)
>
>
> In order to break out from this trap, I have to destroy the credentials of linux:
>
> # su - linux
> $ kdestroy
> $ klist
> klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_500)
>
> Kerberos 4 ticket cache: /tmp/tkt500
> klist: You have no tickets cached
>
> $ logout
>
> # mount lucy2_10g:/
>
> Now it vorks:
>
>
> handling krb5 upcall
> getting credentials for client with uid 0 for server lucy2_10g.frec.bull.fr
> CC file 'krb5cc_machine_FREC.BULL.FR' being considered
> CC file 'krb5cc_machine_FREC.BULL.FR' matches owner check and has mtime of 1181136512
> CC file 'krb5cc_0' being considered
> CC file 'krb5cc_0' matches owner check and has mtime of 1182503308
> CC file 'krb5cc_0' is our current best match with mtime of 1182503308
> using FILE:/tmp/krb5cc_0 as credentials cache for client with uid 0 for server lucy2_10g.frec.bull.fr
> using environment variable to select krb5 ccache FILE:/tmp/krb5cc_0
> creating context using fsuid 0 (save_uid 0)
> creating tcp client for server lucy2_10g.frec.bull.fr
> creating context with server nfs at lucy2_10g.frec.bull.fr
> serialize_krb5_ctx: serializing keys with enctype 4 and length 8
> doing downcall
>
> leaving poll
> handling null request
> readline: read 940 chars into buffer of size 2048: \x \x608201cf06092a864886f71201020201006e8201be308201baa003020105a10302010ea20703050020000000a381fb6181f83081f5a003020105a10e1b0c465245432e42554c4c2e4652a2283026a003020103a11f301d1b036e66731b166c756379325f3130672e667265632e62756c6c2e6672a381b33081b0a003020101a103020105a281a30481a0920726229e3d7c5807eb735204e7391e36b9dc597bc27c53a7b6dc97130781e6cacab0eb2e305bea7f63f2dcfdde781ec4eb9cb892f81a3627ef3061f5b58a671cf82956cf186f542abfa7cf81e00a347b3...
> in_handle:
> length 0
>
> in_tok:
> length 467
>
> 0000: 6082 01cf 0609 2a86 4886 f712 0102 0201 `.....*.H.......
> 0010: 006e 8201 be30 8201 baa0 0302 0105 a103 .n...0..........
> 0020: 0201 0ea2 0703 0500 2000 0000 a381 fb61 ........ ......a
> 0030: 81f8 3081 f5a0 0302 0105 a10e 1b0c 4652 ..0...........FR
> 0040: 4543 2e42 554c 4c2e 4652 a228 3026 a003 EC.BULL.FR.(0&..
> 0050: 0201 03a1 1f30 1d1b 036e 6673 1b16 6c75 .....0...nfs..lu
> 0060: 6379 325f 3130 672e 6672 6563 2e62 756c cy2_10g.frec.bul
> 0070: 6c2e 6672 a381 b330 81b0 a003 0201 01a1 l.fr...0........
> 0080: 0302 0105 a281 a304 81a0 9207 2622 9e3d ............&".=
> 0090: 7c58 07eb 7352 04e7 391e 36b9 dc59 7bc2 |X..sR..9.6..Y{.
> 00a0: 7c53 a7b6 dc97 1307 81e6 caca b0eb 2e30 |S.............0
> 00b0: 5bea 7f63 f2dc fdde 781e c4eb 9cb8 92f8 [..c....x.......
> 00c0: 1a36 27ef 3061 f5b5 8a67 1cf8 2956 cf18 .6'.0a...g..)V..
> 00d0: 6f54 2abf a7cf 81e0 0a34 7b30 6848 0cfe oT*......4{0hH..
> 00e0: a4d5 6f47 3c5d a8ce 2de3 b93c 559d b945 ..oG<]..-..<U..E
> 00f0: 1c1d f25a 5581 1092 4fa5 538f a516 0647 ...ZU...O.S....G
> 0100: 4024 50ce 4dd5 2cf9 c6f1 cd3c e466 3708 @$P.M.,....<.f7.
> 0110: cb7d 3f76 f163 9710 fe65 0bc8 8c35 80f1 .}?v.c...e...5..
> 0120: 71d9 d89c 014f 52f7 7090 a481 a630 81a3 q....OR.p....0..
> 0130: a003 0201 01a2 819b 0481 98b0 33f4 f1cc ............3...
> 0140: 6b4b 65f6 fcf0 ac35 f823 a141 e06c 26af kKe....5.#.A.l&.
> 0150: 6435 eb95 8a6f abc4 67dd 489e cdc4 55c3 d5...o..g.H...U.
> 0160: edd3 de3e f06a dab2 5eec 7ec9 6d76 4d23 ...>.j..^.~.mvM#
> 0170: 669c 1a97 6cb4 9404 b237 1f02 e0e2 869c f...l....7......
> 0180: 3edf 6533 e7d6 2be7 4d00 1a43 d30b 7470 >.e3..+.M..C..tp
> 0190: b2ea b3fc 5f38 f8d9 2339 d449 39e9 e93e ...._8..#9.I9..>
> 01a0: 169a 7ca8 8cac 697c b9e7 4a03 522e 656d ..|...i|..J.R.em
> 01b0: 2ca5 4acf adf5 5f4a b4e2 ad2e 8d63 cd52 ,.J..._J.....c.R
> 01c0: 7d97 353c 275c 1ef2 1b1d f9ec c648 8286 }.5<'\.......H..
> 01d0: 75b4 04 u..
> Jun22 11:09:38 lucy2 rpc.svcgssd[19713]: sname = root at FREC.BULL.FR
> Jun22 11:09:38 lucy2 rpc.svcgssd[19713]: nss_getpwnam: name 'root at FREC.BULL.FR' domain '(null)': resulting localname 'root'
> Jun22 11:09:38 lucy2 rpc.svcgssd[19713]: nss_getpwnam: name 'root at FREC.BULL.FR' domain '(null)': resulting localname 'root'
> Jun22 11:09:38 lucy2 rpc.svcgssd[19713]: serialize_krb5_ctx: serializing keys with enctype 4 and length 8
> Jun22 11:09:38 lucy2 rpc.svcgssd[19713]: doing downcall
> Jun22 11:09:38 lucy2 rpc.svcgssd[19713]: \x09000000 2147483647 0 0 7 0 1 2 3 4 6 10 krb5 \x000000000000000000000000000000000000000000000000000000000000000003e37c4643043919090000002a864886f7120102020400000008000000b65452e65273104c040000000800000046a4a216a283e0bc
> Jun22 11:09:38 lucy2 rpc.svcgssd[19713]: sending null reply
> Jun22 11:09:38 lucy2 rpc.svcgssd[19713]: writing message: \x \x608201cf06092a864886f71201020201006e8201be308201baa003020105a10302010ea20703050020000000a381fb6181f83081f5a003020105a10e1b0c465245432e42554c4c2e4652a2283026a003020103a11f301d1b036e66731b166c756379325f3130672e667265632e62756c6c2e6672a381b33081b0a003020101a103020105a281a30481a0920726229e3d7c5807eb735204e7391e36b9dc597bc27c53a7b6dc97130781e6cacab0eb2e305bea7f63f2dcfdde781ec4eb9cb892f81a3627ef3061f5b58a671cf82956cf186f542abfa7cf81e00a347b3068480cfea4d56f473c5da8ce2de3b93c5...
> Jun22 11:09:38 lucy2 rpc.svcgssd[19713]: finished handling null request
> Jun22 11:09:38 lucy2 kernel: kernel unaligned access to 0xe000000838c10027, ip=0xa000000204be0e51
> Jun22 11:09:38 lucy2 rpc.svcgssd[19713]: entering poll
>
>
> I use the un-tar'ed libs + nfs-utils you sent me.
>
>
> Thanks,
>
> Zoltan
>
> FYI... I'll be away next week :-(
I'll be away next week as well :-)
I cannot make sense of this. The same user and credentials are
involved in the case where it works and the case where it doesn't.
The existence of user 'linux' credentials should not be involved at
all, and should not make a difference. Are you sure that it is not
simply the second attempt as root, regardless of the existence of
'linux' credentials, that works?
In both cases the mapping from the principal to the local user is to
'root', which should get squashed to nfsnobody because of
root_squashing. It looks like the gss context negotiation works in
both cases, but something else is failing the mount in the first case.
A network trace on the client might give a clue.
K.C.
More information about the NFSv4
mailing list