NFSv4 backchannel authentication
Subsystems (2)
Hello,
it seems that RHEL NFSv4 servers use GSS authentication for backchannels as well (if mount it with GSS). That would be OK, but it requires that server is running rpc.gssd and the client is running rpc.svcgssd, which is not usual.
Is there a way how to mount clients with sec=krb5/i/p and use backchannels just with UNIX auth?
Signature · 1 line
Lukáš Hejtmánek
Quoted 3 lines · Lukas Hejtmanek
it seems that RHEL NFSv4 servers use GSS authentication for backchannels as well (if mount it with GSS). That would be OK, but it requires that server is running rpc.gssd and the client is running rpc.svcgssd, which is not usual.
The init scripts probably need to be fixed to start both in both cases. Worth filing a bug, I think.
Quoted 2 lines
Is there a way how to mount clients with sec=krb5/i/p and use backchannels just with UNIX auth?
Not with NFSv4; from http://www.ietf.org/rfc/rfc3530.txt section 3.4:
"Except as noted elsewhere in this section, the callback RPC (described later) MUST mutually authenticate the NFS server to the principal that acquired the clientid (also described later), using the security flavor the original SETCLIENTID operation used."
(Actually, perhaps there's a loophole that would allow SETCLIENTID to be done with auth_sys while file access is still done with gss. I don't think so, but I forget the details. In practice the clients do all use gss.)
4.1 does allow the client to request a different security flavor on the backchannel, and the linux client does use auth_sys on the backchannel even when using gss on the forechannel.
--b.
T24gVHVlLCAyMDEyLTA4LTA3IGF0IDExOjQxIC0wNDAwLCBKLiBCcnVjZSBGaWVsZHMgd3JvdGU6 DQo+IE9uIE1vbiwgQXVnIDA2LCAyMDEyIGF0IDAzOjU1OjE3UE0gKzAyMDAsIEx1a2FzIEhlanRt YW5layB3cm90ZToNCj4gPiBpdCBzZWVtcyB0aGF0IFJIRUwgTkZTdjQgc2VydmVycyB1c2UgR1NT IGF1dGhlbnRpY2F0aW9uIGZvciBiYWNrY2hhbm5lbHMgYXMNCj4gPiB3ZWxsIChpZiBtb3VudCBp dCB3aXRoIEdTUykuIFRoYXQgd291bGQgYmUgT0ssIGJ1dCBpdCByZXF1aXJlcyB0aGF0IHNlcnZl ciBpcw0KPiA+IHJ1bm5pbmcgcnBjLmdzc2QgYW5kIHRoZSBjbGllbnQgaXMgcnVubmluZyBycGMu c3ZjZ3NzZCwgd2hpY2ggaXMgbm90IHVzdWFsLg0KPiANCj4gVGhlIGluaXQgc2NyaXB0cyBwcm9i YWJseSBuZWVkIHRvIGJlIGZpeGVkIHRvIHN0YXJ0IGJvdGggaW4gYm90aCBjYXNlcy4NCj4gV29y dGggZmlsaW5nIGEgYnVnLCBJIHRoaW5rLg0KPiANCj4gPiBJcyB0aGVyZSBhIHdheSBob3cgdG8g bW91bnQgY2xpZW50cyB3aXRoIHNlYz1rcmI1L2kvcCBhbmQgdXNlIGJhY2tjaGFubmVscyBqdXN0 DQo+ID4gd2l0aCBVTklYIGF1dGg/DQo+IA0KPiBOb3Qgd2l0aCBORlN2NDsgZnJvbSBodHRwOi8v d3d3LmlldGYub3JnL3JmYy9yZmMzNTMwLnR4dCBzZWN0aW9uIDMuNDoNCj4gDQo+IAkiRXhjZXB0 IGFzIG5vdGVkIGVsc2V3aGVyZSBpbiB0aGlzIHNlY3Rpb24sIHRoZSBjYWxsYmFjayBSUEMNCj4g CShkZXNjcmliZWQgbGF0ZXIpIE1VU1QgbXV0dWFsbHkgYXV0aGVudGljYXRlIHRoZSBORlMgc2Vy dmVyIHRvDQo+IAl0aGUgcHJpbmNpcGFsIHRoYXQgYWNxdWlyZWQgdGhlIGNsaWVudGlkIChhbHNv IGRlc2NyaWJlZCBsYXRlciksDQo+IAl1c2luZyB0aGUgc2VjdXJpdHkgZmxhdm9yIHRoZSBvcmln aW5hbCBTRVRDTElFTlRJRCBvcGVyYXRpb24NCj4gCXVzZWQuIg0KPiANCj4gKEFjdHVhbGx5LCBw ZXJoYXBzIHRoZXJlJ3MgYSBsb29waG9sZSB0aGF0IHdvdWxkIGFsbG93IFNFVENMSUVOVElEIHRv IGJlDQo+IGRvbmUgd2l0aCBhdXRoX3N5cyB3aGlsZSBmaWxlIGFjY2VzcyBpcyBzdGlsbCBkb25l IHdpdGggZ3NzLiAgSSBkb24ndA0KPiB0aGluayBzbywgYnV0IEkgZm9yZ2V0IHRoZSBkZXRhaWxz LiAgSW4gcHJhY3RpY2UgdGhlIGNsaWVudHMgZG8gYWxsIHVzZQ0KPiBnc3MuKQ0KDQpZZXMsIHlv dSBjYW4gZG8gdGhpcywgaG93ZXZlciB0aGF0IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgdG8gYmUgY29u ZmlndXJlZA0KdG8gYWNjZXB0IHJwY3NlY19nc3MgYW5kIGF1dGhfc3lzIGZyb20gdGhhdCBjbGll bnQuDQpJdCBhbHNvIGFsbG93cyBhbnlvbmUgdG8gc3Bvb2YgYSBjYWxsYmFjayB0byB5b3VyIGNs aWVudC4NCkZ1cnRoZXJtb3JlLCBpdCB3b3VsZCBhbGxvdyBhbnlib2R5IHRvIHNlbmQgU0VUQ0xJ RU5USUQgY2FsbHMgdXNpbmcgdGhlDQpzYW1lIGNsaWVudCBpZCB0byB0aGUgc2VydmVyIGFuZCBz byB0aGV5IGNhbiBkZWNsYXJlIHlvdXIgY2xpZW50IHRvIGhhdmUNCnJlYm9vdGVkIChzbyB0aGF0 IGFsbCBzdGF0ZSBpcyBsb3N0KSwgdGhleSBjYW4gZGl2ZXJ0IGNhbGxiYWNrcyB0bw0KYW5vdGhl ciBtYWNoaW5lLCAuLi4uDQpJT1c6IGl0IGlzIG5vdCByZWFsbHkgc29tZXRoaW5nIHlvdSB3YW50 IHRvIGFsbG93IG9uIGFuIHVudHJ1c3RlZA0KbmV0d29yay4NCg0KPiA0LjEgZG9lcyBhbGxvdyB0 aGUgY2xpZW50IHRvIHJlcXVlc3QgYSBkaWZmZXJlbnQgc2VjdXJpdHkgZmxhdm9yIG9uIHRoZQ0K PiBiYWNrY2hhbm5lbCwgYW5kIHRoZSBsaW51eCBjbGllbnQgZG9lcyB1c2UgYXV0aF9zeXMgb24g dGhlIGJhY2tjaGFubmVsDQo+IGV2ZW4gd2hlbiB1c2luZyBnc3Mgb24gdGhlIGZvcmVjaGFubmVs Lg0KDQpZZXMsIGFuZCB0aGF0IGxlYXZlcyBhIGxlc3Mgcm9vbSBmb3Igc3Bvb2ZpbmcgYmVjYXVz ZSB0aGUgYmFjayBjaGFubmVsDQpjb25uZWN0aW9uIGlzIHNldCB1cCBieSB0aGUgY2xpZW50Lg0K DQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5l dEFwcA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg==
Quoted 9 lines · Trond
Yes, you can do this, however that requires the server to be configured to accept
rpcsec_gssandauth_sysfrom that client.
It also allows anyone to spoof a callback to your client. Furthermore, it would allow anybody to send SETCLIENTID calls using the same client id to the server and so they can declare your client to have rebooted (so that all state is lost), they can divert callbacks to another machine, ....
IOW: it is not really something you want to allow on an untrusted network.
well, ok, thanks for anwsers. However, it seems that while NFS server's name is server-home.domain.com (floating name), and true hostname is server1.domain.com, it does not matter that callback is authenticated with server1.domain.com instead of server-home.domain.com.
Is this expected? Or is it a bug?
I would suppose that client rejects authentication of the backchannel from server that sends nfs/server1.domain.com KRB principal instead of expected nfs/server-home.domain.com.
The client mounts server-home.domain.com with sec=krb5i. Using debugs I can see that the server picks up nfs/server1.domain.com key from /etc/krb5.keytab and the client seems to be happy with that (context is established).
Signature · 1 line
Lukáš Hejtmánek
Quoted 6 lines · Lukas Hejtmanek
well, ok, thanks for anwsers. However, it seems that while NFS server's name is server-home.domain.com (floating name), and true hostname is server1.domain.com, it does not matter that callback is authenticated with server1.domain.com instead of server-home.domain.com.
Is this expected? Or is it a bug?
It does matter, callback client name must match the name NFS client uses for server.
We don't see any hard failures because NFS protocol does
not depend on working callback RPCs, but no delegations are granted (we had nfs-kernel-server package installed on clients before which masked the bug).
Quoted 7 lines
I would suppose that client rejects authentication of the backchannel from server that sends nfs/server1.domain.com KRB principal instead of expected nfs/server-home.domain.com.
The client mounts server-home.domain.com with sec=krb5i. Using debugs I can see that the server picks up nfs/server1.domain.com key from
/etc/krb5.keytaband the client seems to be happy with that (context is established).
Server name is checked later, when the context is used for actual callback RPC.
Best regards,
Zdenek Salvet [email protected]
Institute of Computer Science of Masaryk University, Brno, Czech Republic and CESNET, z.s.p.o., Prague, Czech Republic
Phone: ++420-549 49 6534 Fax: ++420-541 212 747
----------------------------------------------------------------------------
Teamwork is essential -- it allows you to blame someone else.
T24gV2VkLCAyMDEyLTA4LTA4IGF0IDA5OjU4ICswMjAwLCBaZGVuZWsgU2FsdmV0IHdyb3RlOg0K PiBPbiBUdWUsIEF1ZyAwNywgMjAxMiBhdCAxODoxMjoxMSArMDIwMCwgTHVrYXMgSGVqdG1hbmVr IHdyb3RlOg0KPiA+IHdlbGwsIG9rLCB0aGFua3MgZm9yIGFud3NlcnMuIEhvd2V2ZXIsIGl0IHNl ZW1zIHRoYXQgd2hpbGUgTkZTIHNlcnZlcidzIG5hbWUNCj4gPiBpcyBzZXJ2ZXItaG9tZS5kb21h aW4uY29tIChmbG9hdGluZyBuYW1lKSwgYW5kIHRydWUgaG9zdG5hbWUgaXMNCj4gPiBzZXJ2ZXIx LmRvbWFpbi5jb20sIGl0IGRvZXMgbm90IG1hdHRlciB0aGF0IGNhbGxiYWNrIGlzIGF1dGhlbnRp Y2F0ZWQgd2l0aA0KPiA+IHNlcnZlcjEuZG9tYWluLmNvbSBpbnN0ZWFkIG9mIHNlcnZlci1ob21l LmRvbWFpbi5jb20uDQo+ID4gDQo+ID4gSXMgdGhpcyBleHBlY3RlZD8gT3IgaXMgaXQgYSBidWc/ DQo+IA0KPiBJdCBkb2VzIG1hdHRlciwgY2FsbGJhY2sgY2xpZW50IG5hbWUgbXVzdCBtYXRjaCB0 aGUgbmFtZSBORlMgY2xpZW50IHVzZXMNCj4gZm9yIHNlcnZlci4gDQo+IA0KPiBXZSBkb24ndCBz ZWUgYW55IGhhcmQgZmFpbHVyZXMgYmVjYXVzZSBORlMgcHJvdG9jb2wgZG9lcw0KPiBub3QgZGVw ZW5kIG9uIHdvcmtpbmcgY2FsbGJhY2sgUlBDcywgYnV0IG5vIGRlbGVnYXRpb25zIGFyZSBncmFu dGVkDQo+ICh3ZSBoYWQgbmZzLWtlcm5lbC1zZXJ2ZXIgcGFja2FnZSBpbnN0YWxsZWQgb24gY2xp ZW50cyBiZWZvcmUgd2hpY2ggbWFza2VkDQo+IHRoZSBidWcpLg0KDQpTbyB5b3VyIGdyaXBlIHRo YXQgeW91IG9iamVjdCB0byB1cyByZXF1aXJpbmcgeW91IHRvIHJ1biBycGMuc3ZjZ3NzZCBpbg0K b3JkZXIgdG8gb2J0YWluIHNlcnZlciBmZWF0dXJlcyBzdWNoIGFzIE5GU3Y0IGNhbGxiYWNrcz8N Cg0KV2h5IHNob3VsZCB3ZSBjYXJlPw0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZT IGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFwcA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20N Cnd3dy5uZXRhcHAuY29tDQoNCg==
Quoted 7 lines · Trond
Quoted 4 lines
We don't see any hard failures because NFS protocol does
not depend on working callback RPCs, but no delegations are granted (we had nfs-kernel-server package installed on clients before which masked the bug).So your gripe that you object to us requiring you to run rpc.svcgssd in order to obtain server features such as NFSv4 callbacks?
Absolutely not! Just thinking why we did not notice the problem earlier ...
Signature · 6 lines
Zdenek Salvet [email protected] Institute of Computer Science of Masaryk University, Brno, Czech Republic and CESNET, z.s.p.o., Prague, Czech Republic Phone: ++420-549 49 6534 Fax: ++420-541 212 747 ---------------------------------------------------------------------------- Teamwork is essential -- it allows you to blame someone else.
Quoted 10 lines · Zdenek Salvet
Quoted 7 lines · Trond
Quoted 4 lines
We don't see any hard failures because NFS protocol does
not depend on working callback RPCs, but no delegations are granted (we had nfs-kernel-server package installed on clients before which masked the bug).So your gripe that you object to us requiring you to run rpc.svcgssd in order to obtain server features such as NFSv4 callbacks?
Absolutely not! Just thinking why we did not notice the problem earlier ...
I wonder if there's anything we could do to make this more automatic,
though: e.g., perhaps whichever scripts are launching one of the gss daemons should be replaced by one that launches both, since that's generally what you'll want for NFSv4.0. (Not necessary for other versions, but it doesn't hurt much.)
Or perhaps they could be started on demand somehow.
--b.
T24gVGh1LCAyMDEyLTA4LTA5IGF0IDEwOjQ1IC0wNDAwLCBKLiBCcnVjZSBGaWVsZHMgd3JvdGU6 DQo+IE9uIFRodSwgQXVnIDA5LCAyMDEyIGF0IDEwOjA2OjQyQU0gKzAyMDAsIFpkZW5layBTYWx2 ZXQgd3JvdGU6DQo+ID4gT24gV2VkLCBBdWcgMDgsIDIwMTIgYXQgMDE6MTg6MDlQTSArMDAwMCwg TXlrbGVidXN0LCBUcm9uZCB3cm90ZToNCj4gPiA+ID4gV2UgZG9uJ3Qgc2VlIGFueSBoYXJkIGZh aWx1cmVzIGJlY2F1c2UgTkZTIHByb3RvY29sIGRvZXMNCj4gPiA+ID4gbm90IGRlcGVuZCBvbiB3 b3JraW5nIGNhbGxiYWNrIFJQQ3MsIGJ1dCBubyBkZWxlZ2F0aW9ucyBhcmUgZ3JhbnRlZA0KPiA+ ID4gPiAod2UgaGFkIG5mcy1rZXJuZWwtc2VydmVyIHBhY2thZ2UgaW5zdGFsbGVkIG9uIGNsaWVu dHMgYmVmb3JlIHdoaWNoIG1hc2tlZA0KPiA+ID4gPiB0aGUgYnVnKS4NCj4gPiA+IA0KPiA+ID4g U28geW91ciBncmlwZSB0aGF0IHlvdSBvYmplY3QgdG8gdXMgcmVxdWlyaW5nIHlvdSB0byBydW4g cnBjLnN2Y2dzc2QgaW4NCj4gPiA+IG9yZGVyIHRvIG9idGFpbiBzZXJ2ZXIgZmVhdHVyZXMgc3Vj aCBhcyBORlN2NCBjYWxsYmFja3M/DQo+ID4gDQo+ID4gQWJzb2x1dGVseSBub3QhIEp1c3QgdGhp bmtpbmcgd2h5IHdlIGRpZCBub3Qgbm90aWNlIHRoZSBwcm9ibGVtIGVhcmxpZXIgLi4uDQo+IA0K PiBJIHdvbmRlciBpZiB0aGVyZSdzIGFueXRoaW5nIHdlIGNvdWxkIGRvIHRvIG1ha2UgdGhpcyBt b3JlIGF1dG9tYXRpYywNCj4gdGhvdWdoOiBlLmcuLCBwZXJoYXBzIHdoaWNoZXZlciBzY3JpcHRz IGFyZSBsYXVuY2hpbmcgb25lIG9mIHRoZSBnc3MNCj4gZGFlbW9ucyBzaG91bGQgYmUgcmVwbGFj ZWQgYnkgb25lIHRoYXQgbGF1bmNoZXMgYm90aCwgc2luY2UgdGhhdCdzDQo+IGdlbmVyYWxseSB3 aGF0IHlvdSdsbCB3YW50IGZvciBORlN2NC4wLiAgKE5vdCBuZWNlc3NhcnkgZm9yIG90aGVyDQo+ IHZlcnNpb25zLCBidXQgaXQgZG9lc24ndCBodXJ0IG11Y2guKQ0KPiANCj4gT3IgcGVyaGFwcyB0 aGV5IGNvdWxkIGJlIHN0YXJ0ZWQgb24gZGVtYW5kIHNvbWVob3cuDQoNCkhvdyBpcyB0aGlzIGFu eSBkaWZmZXJlbnQgdG8gcmVxdWlyaW5nIHRoYXQgdGhlIHVzZXIgc3RhcnQgcnBjLnN0YXRkDQpi ZWZvcmUgbGF1bmNoaW5nIGFuIE5GU3YzIG1vdW50PyBKdXN0IGRvY3VtZW50IHRoZSByZXF1aXJl bWVudCBpZiBpdA0KaXNuJ3QgYWxyZWFkeSBjbGVhciBlbm91Z2gsIGFuZCB3ZSBjYW4gbW92ZSBv bi4NCg0KVGhlIG90aGVyIHNvdXJjZSBvZiBjb25mdXNpb24gaGVyZSwgd2FzIHRoYXQgdGhlIHJw Yy5zdmNnc3NkIHdhcw0KZGVsaXZlcmVkIHRocm91Z2ggYSBuZnMta2VybmVsLXNlcnZlciBwYWNr YWdlLCB3aGljaCBpbmRpY2F0ZXMgdGhhdCB3ZQ0KZmlyc3QgYW5kIGZvcmVtb3N0IG5lZWQgdG8g ZWR1Y2F0ZSB0aGUgZGlzdHJvIHBhY2thZ2Vycy4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxp bnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRh cHAuY29tDQp3d3cubmV0YXBwLmNvbQ0KDQo=
Quoted 7 lines · Trond
How is this any different to requiring that the user start rpc.statd before launching an NFSv3 mount? Just document the requirement if it isn't already clear enough, and we can move on.
The other source of confusion here, was that the rpc.svcgssd was delivered through a nfs-kernel-server package, which indicates that we first and foremost need to educate the distro packagers.
hmm, if both rpc.gssd and rpc.svcgssd are needed on clients and servers, isn't it worth of merging them into a single process?
Signature · 1 line
Lukáš Hejtmánek
T24gVGh1LCAyMDEyLTA4LTA5IGF0IDE4OjI4ICswMjAwLCBMdWthcyBIZWp0bWFuZWsgd3JvdGU6 DQo+IE9uIFRodSwgQXVnIDA5LCAyMDEyIGF0IDAzOjUzOjAxUE0gKzAwMDAsIE15a2xlYnVzdCwg VHJvbmQgd3JvdGU6DQo+ID4gSG93IGlzIHRoaXMgYW55IGRpZmZlcmVudCB0byByZXF1aXJpbmcg dGhhdCB0aGUgdXNlciBzdGFydCBycGMuc3RhdGQNCj4gPiBiZWZvcmUgbGF1bmNoaW5nIGFuIE5G U3YzIG1vdW50PyBKdXN0IGRvY3VtZW50IHRoZSByZXF1aXJlbWVudCBpZiBpdA0KPiA+IGlzbid0 IGFscmVhZHkgY2xlYXIgZW5vdWdoLCBhbmQgd2UgY2FuIG1vdmUgb24uDQo+ID4gDQo+ID4gVGhl IG90aGVyIHNvdXJjZSBvZiBjb25mdXNpb24gaGVyZSwgd2FzIHRoYXQgdGhlIHJwYy5zdmNnc3Nk IHdhcw0KPiA+IGRlbGl2ZXJlZCB0aHJvdWdoIGEgbmZzLWtlcm5lbC1zZXJ2ZXIgcGFja2FnZSwg d2hpY2ggaW5kaWNhdGVzIHRoYXQgd2UNCj4gPiBmaXJzdCBhbmQgZm9yZW1vc3QgbmVlZCB0byBl ZHVjYXRlIHRoZSBkaXN0cm8gcGFja2FnZXJzLg0KPiANCj4gaG1tLCBpZiBib3RoIHJwYy5nc3Nk IGFuZCBycGMuc3ZjZ3NzZCBhcmUgbmVlZGVkIG9uIGNsaWVudHMgYW5kIHNlcnZlcnMsIGlzbid0 DQo+IGl0IHdvcnRoIG9mIG1lcmdpbmcgdGhlbSBpbnRvIGEgc2luZ2xlIHByb2Nlc3M/DQoNCllv dSBkb24ndCBuZWVkIHJwYy5nc3NkIHRvIHVzZSBycGNzZWNfZ3NzIHdpdGggTkZTdjMsIG5vciBk byB5b3UgbmVlZCBpdA0KaWYgeW91J3JlIG5vdCBpbnRlbmRpbmcgb24gdXNpbmcgZGVsZWdhdGlv bnMgd2l0aCBORlN2NC4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQg bWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0 YXBwLmNvbQ0KDQo=
Quoted 6 lines · Trond
Quoted 5 lines · Lukas Hejtmanek
Quoted 4 lines · Trond
How is this any different to requiring that the user start rpc.statd before launching an NFSv3 mount? Just document the requirement if it isn't already clear enough, and we can move on.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
The other source of confusion here, was that the rpc.svcgssd was delivered through a nfs-kernel-server package, which indicates that we first and foremost need to educate the distro packagers.
hmm, if both rpc.gssd and rpc.svcgssd are needed on clients and servers, isn't it worth of merging them into a single process?
You don't need rpc.gssd to use
rpcsec_gsswith NFSv3, nor do you need it
^^^^^^^^
You meant rpc.svcgssd, unless you were thinking about the nfsd side.
Quoted 1 line
if you're not intending on using delegations with NFSv4.
Though the default should be to support delegations.
--b.
T24gVGh1LCAyMDEyLTA4LTA5IGF0IDEyOjM4IC0wNDAwLCBKLiBCcnVjZSBGaWVsZHMgd3JvdGU6 DQo+IE9uIFRodSwgQXVnIDA5LCAyMDEyIGF0IDA0OjMwOjUzUE0gKzAwMDAsIE15a2xlYnVzdCwg VHJvbmQgd3JvdGU6DQo+ID4gT24gVGh1LCAyMDEyLTA4LTA5IGF0IDE4OjI4ICswMjAwLCBMdWth cyBIZWp0bWFuZWsgd3JvdGU6DQo+ID4gPiBPbiBUaHUsIEF1ZyAwOSwgMjAxMiBhdCAwMzo1Mzow MVBNICswMDAwLCBNeWtsZWJ1c3QsIFRyb25kIHdyb3RlOg0KPiA+ID4gPiBIb3cgaXMgdGhpcyBh bnkgZGlmZmVyZW50IHRvIHJlcXVpcmluZyB0aGF0IHRoZSB1c2VyIHN0YXJ0IHJwYy5zdGF0ZA0K PiA+ID4gPiBiZWZvcmUgbGF1bmNoaW5nIGFuIE5GU3YzIG1vdW50PyBKdXN0IGRvY3VtZW50IHRo ZSByZXF1aXJlbWVudCBpZiBpdA0KPiA+ID4gPiBpc24ndCBhbHJlYWR5IGNsZWFyIGVub3VnaCwg YW5kIHdlIGNhbiBtb3ZlIG9uLg0KPiA+ID4gPiANCj4gPiA+ID4gVGhlIG90aGVyIHNvdXJjZSBv ZiBjb25mdXNpb24gaGVyZSwgd2FzIHRoYXQgdGhlIHJwYy5zdmNnc3NkIHdhcw0KPiA+ID4gPiBk ZWxpdmVyZWQgdGhyb3VnaCBhIG5mcy1rZXJuZWwtc2VydmVyIHBhY2thZ2UsIHdoaWNoIGluZGlj YXRlcyB0aGF0IHdlDQo+ID4gPiA+IGZpcnN0IGFuZCBmb3JlbW9zdCBuZWVkIHRvIGVkdWNhdGUg dGhlIGRpc3RybyBwYWNrYWdlcnMuDQo+ID4gPiANCj4gPiA+IGhtbSwgaWYgYm90aCBycGMuZ3Nz ZCBhbmQgcnBjLnN2Y2dzc2QgYXJlIG5lZWRlZCBvbiBjbGllbnRzIGFuZCBzZXJ2ZXJzLCBpc24n dA0KPiA+ID4gaXQgd29ydGggb2YgbWVyZ2luZyB0aGVtIGludG8gYSBzaW5nbGUgcHJvY2Vzcz8N Cj4gPiANCj4gPiBZb3UgZG9uJ3QgbmVlZCBycGMuZ3NzZCB0byB1c2UgcnBjc2VjX2dzcyB3aXRo IE5GU3YzLCBub3IgZG8geW91IG5lZWQgaXQNCj4gCQkgXl5eXl5eXl4NCj4gDQo+IFlvdSBtZWFu dCBycGMuc3ZjZ3NzZCwgdW5sZXNzIHlvdSB3ZXJlIHRoaW5raW5nIGFib3V0IHRoZSBuZnNkIHNp ZGUuDQoNClllcy4NCg0KPiA+IGlmIHlvdSdyZSBub3QgaW50ZW5kaW5nIG9uIHVzaW5nIGRlbGVn YXRpb25zIHdpdGggTkZTdjQuDQo+IA0KPiBUaG91Z2ggdGhlIGRlZmF1bHQgc2hvdWxkIGJlIHRv IHN1cHBvcnQgZGVsZWdhdGlvbnMuDQoNClJpZ2h0LCBidXQgdGhhdCBpc24ndCBhIGp1c3RpZmlj YXRpb24gZm9yIG1ha2luZyBpdCBpbXBvc3NpYmxlIHRvIHJ1bg0Kd2l0aG91dCBycGMuc3ZjZ3Nz ZCBpZiB5b3UgZG9uJ3QgbmVlZCBpdC4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5G UyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29t DQp3d3cubmV0YXBwLmNvbQ0KDQo=
Quoted 19 lines · Trond
Quoted 18 lines · J. Bruce Fields
Quoted 10 lines · Zdenek Salvet
Quoted 7 lines · Trond
Quoted 4 lines
We don't see any hard failures because NFS protocol does
not depend on working callback RPCs, but no delegations are granted (we had nfs-kernel-server package installed on clients before which masked the bug).So your gripe that you object to us requiring you to run rpc.svcgssd in order to obtain server features such as NFSv4 callbacks?
Absolutely not! Just thinking why we did not notice the problem earlier ...
I wonder if there's anything we could do to make this more automatic,
though: e.g., perhaps whichever scripts are launching one of the gss daemons should be replaced by one that launches both, since that's generally what you'll want for NFSv4.0. (Not necessary for other versions, but it doesn't hurt much.)
Quoted 5 lines
Quoted 1 line
Or perhaps they could be started on demand somehow.
How is this any different to requiring that the user start rpc.statd before launching an NFSv3 mount? Just document the requirement if it isn't already clear enough, and we can move on.
That's good enough, but it's always nice if there's some configuration we can skip. (Not that I'm volunteering.)
Quoted 3 lines
The other source of confusion here, was that the rpc.svcgssd was delivered through a nfs-kernel-server package, which indicates that we first and foremost need to educate the distro packagers.
Yes, that's a mistake. The nfs-utils README is where we've been documenting daemon startup--I'll work on a patch. (And see if the man pages could use something too.) And somebody should ping Debian (nfs-kernel-server sounds like a Debian thing.)
--b.
Quoted 8 lines · J. Bruce Fields
Quoted 3 lines
The other source of confusion here, was that the rpc.svcgssd was delivered through a nfs-kernel-server package, which indicates that we first and foremost need to educate the distro packagers.
Yes, that's a mistake. The nfs-utils README is where we've been documenting daemon startup--I'll work on a patch. (And see if the man pages could use something too.) And somebody should ping Debian (nfs-kernel-server sounds like a Debian thing.)
I sent bug report to Debian Bug Tracking System. Other distributions may need a notice too, at least SLES<=11.1 and RHEL<=6.3 did not figure it out themselves AFAICT ...
Best regards,
Zdenek Salvet [email protected]
Institute of Computer Science of Masaryk University, Brno, Czech Republic and CESNET, z.s.p.o., Prague, Czech Republic
Phone: ++420-549 49 6534 Fax: ++420-541 212 747
----------------------------------------------------------------------------
Teamwork is essential -- it allows you to blame someone else.
PATCH 1/1 README: note gssd/svcgssd may be needed on both sides
In reply to J. Bruce FieldsFrom: "J. Bruce Fields" <[email protected]>
Administrators and distributors have been confused about this.
--- README | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
README +13 -5
@@ -71,18 +71,21 @@ scripts can be written to work correctly. A/ mount -t nfsd /proc/fs/nfsd - This filesystem needs to be mount before most daemons, + This filesystem needs to be mounted before most daemons, particularly exportfs, mountd, svcgssd, idmapd. It could be mounted once, or the script that starts each daemon could test if it is mounted and mount it if not. - B/ svcgssd ; idmapd + B/ svcgssd ; gssd; idmapd These supply services to nfsd and so should be started before rpc.nfsd. Where they come between mounting the nfsd filesystem and starting the nfsd server is not important. idmapd is only needed for NFSv4 support. - svcgssd is only needed if exportfs NFS filesystem with crypto- - security (Kerberos). + svcgssd is needed to export filesystems with Kerberos. + gssd should also be started to support granting delegations to + NFSv4.0 clients using Kerberos. However, if it is not started + this will only mean that delegations will not be granted. This + will not prevent NFSv4.0 clients from functioning normally. C/ exportfs -av ; rpc.mountd It is important that exportfs be run before mountd so that
@@ -148,10 +151,15 @@ scripts can be written to work correctly. filesystems can be mounted with "-o nolock" before sm-notify. This is appropriate for '/', '/usr', and '/var'. - B/ gssd ; idmapd + B/ gssd ; svcgssd; idmapd idmapd should be started before mounting any NFSv4 filesystems. gssd should be started before mounting any NFS filesystems securely (with Kerberos). + Before mounting any NFSv4.0 filesystems with Kerberos, svcgssd should + also be started to support the callbacks required for delegations. + However, a failure to start svcgssd will only mean that delegations + are turned off, and will not prevent such a mount from working + correctly. C/ statd should be run before any NFSv2 or NFSv3 filesystem is mounted with remote locking (i.e. without -o nolock).
Signature · 1 line
1.7.9.5
Quoted 19 lines · Trond
Quoted 18 lines · J. Bruce Fields
Quoted 10 lines · Zdenek Salvet
Quoted 7 lines · Trond
Quoted 4 lines
We don't see any hard failures because NFS protocol does
not depend on working callback RPCs, but no delegations are granted (we had nfs-kernel-server package installed on clients before which masked the bug).So your gripe that you object to us requiring you to run rpc.svcgssd in order to obtain server features such as NFSv4 callbacks?
Absolutely not! Just thinking why we did not notice the problem earlier ...
I wonder if there's anything we could do to make this more automatic,
though: e.g., perhaps whichever scripts are launching one of the gss daemons should be replaced by one that launches both, since that's generally what you'll want for NFSv4.0. (Not necessary for other versions, but it doesn't hurt much.)
Quoted 5 lines
Quoted 1 line
Or perhaps they could be started on demand somehow.
How is this any different to requiring that the user start rpc.statd before launching an NFSv3 mount? Just document the requirement if it isn't already clear enough, and we can move on.
'mount.nfs' checks if statd is running and will start it if it isn't .... which will probably annoy systemd as it likes to keep daemons in their own little box. I guess systemd can be configured to register as statd and auto-start it on the first 'are you there' request.
Could the same thing be done with rpc.svcgssd? Get it to auto-start either by mount.nfs checking and running something, or by systemd pre-registering the RPC port or something?
NeilBrown
Quoted 5 lines
The other source of confusion here, was that the rpc.svcgssd was delivered through a nfs-kernel-server package, which indicates that we first and foremost need to educate the distro packagers.
Quoted 28 lines · NeilBrown
Quoted 19 lines · Trond
Quoted 18 lines · J. Bruce Fields
Quoted 10 lines · Zdenek Salvet
Quoted 7 lines · Trond
Quoted 4 lines
We don't see any hard failures because NFS protocol does
not depend on working callback RPCs, but no delegations are granted (we had nfs-kernel-server package installed on clients before which masked the bug).So your gripe that you object to us requiring you to run rpc.svcgssd in order to obtain server features such as NFSv4 callbacks?
Absolutely not! Just thinking why we did not notice the problem earlier ...
I wonder if there's anything we could do to make this more automatic,
though: e.g., perhaps whichever scripts are launching one of the gss daemons should be replaced by one that launches both, since that's generally what you'll want for NFSv4.0. (Not necessary for other versions, but it doesn't hurt much.)Quoted 5 lines
Quoted 1 line
Or perhaps they could be started on demand somehow.
How is this any different to requiring that the user start rpc.statd before launching an NFSv3 mount? Just document the requirement if it isn't already clear enough, and we can move on.
Quoted 8 lines
'mount.nfs' checks if statd is running and will start it if it isn't .... which will probably annoy systemd as it likes to keep daemons in their own little box. I guess systemd can be configured to register as statd and auto-start it on the first 'are you there' request.
Could the same thing be done with rpc.svcgssd? Get it to auto-start either by mount.nfs checking and running something, or by systemd pre-registering the RPC port or something?
I wonder how hard it would be to teach systemd to do the socket-activation trick with the cache upcalls: so, open the channel file, wait till its readable, then kick off svcgssd and hand off the file descriptor to it.
--b.