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?
--
Luk?? Hejtm?nek
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==
On Thu, Aug 09, 2012 at 10:06:42AM +0200, Zdenek Salvet wrote:
> On Wed, Aug 08, 2012 at 01:18:09PM +0000, Myklebust, Trond wrote:
> > > 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.
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=
On Tue, Aug 07, 2012 at 18:12:11 +0200, Lukas Hejtmanek wrote:
> 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).
> 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).
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.
On Thu, Aug 09, 2012 at 03:53:01PM +0000, Myklebust, Trond wrote:
> On Thu, 2012-08-09 at 10:45 -0400, J. Bruce Fields wrote:
> > On Thu, Aug 09, 2012 at 10:06:42AM +0200, Zdenek Salvet wrote:
> > > On Wed, Aug 08, 2012 at 01:18:09PM +0000, Myklebust, Trond wrote:
> > > > > 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.
>
> 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.)
> 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.
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==
On Tue, Aug 07, 2012 at 03:59:09PM +0000, Myklebust, Trond wrote:
> Yes, you can do this, however that requires the server to be configured
> to accept rpcsec_gss and auth_sys from 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).
--
Luk?? Hejtm?nek
On Mon, Aug 06, 2012 at 03:55:17PM +0200, Lukas Hejtmanek wrote:
> 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.
> 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.
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=
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=
From: "J. Bruce Fields" <[email protected]>
Administrators and distributors have been confused about this.
Signed-off-by: J. Bruce Fields <[email protected]>
---
README | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/README b/README
index e55b2dd..9bb69d7 100644
--- a/README
+++ b/README
@@ -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).
--
1.7.9.5
On Thu, Aug 09, 2012 at 03:53:01PM +0000, Myklebust, Trond wrote:
> 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?
--
Luk?? Hejtm?nek
On Thu, Aug 09, 2012 at 04:30:53PM +0000, Myklebust, Trond wrote:
> On Thu, 2012-08-09 at 18:28 +0200, Lukas Hejtmanek wrote:
> > On Thu, Aug 09, 2012 at 03:53:01PM +0000, Myklebust, Trond wrote:
> > > 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?
>
> You don't need rpc.gssd to use rpcsec_gss with NFSv3, nor do you need it
^^^^^^^^
You meant rpc.svcgssd, unless you were thinking about the nfsd side.
> if you're not intending on using delegations with NFSv4.
Though the default should be to support delegations.
--b.
On Thu, 9 Aug 2012 15:53:01 +0000 "Myklebust, Trond"
<[email protected]> wrote:
> On Thu, 2012-08-09 at 10:45 -0400, J. Bruce Fields wrote:
> > On Thu, Aug 09, 2012 at 10:06:42AM +0200, Zdenek Salvet wrote:
> > > On Wed, Aug 08, 2012 at 01:18:09PM +0000, Myklebust, Trond wrote:
> > > > > 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.
>
> 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
>
> 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.
>
On Wed, Aug 08, 2012 at 01:18:09PM +0000, Myklebust, Trond wrote:
> > 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 ...
--
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.
On Fri, Aug 10, 2012 at 03:20:39PM +1000, NeilBrown wrote:
> On Thu, 9 Aug 2012 15:53:01 +0000 "Myklebust, Trond"
> <[email protected]> wrote:
>
> > On Thu, 2012-08-09 at 10:45 -0400, J. Bruce Fields wrote:
> > > On Thu, Aug 09, 2012 at 10:06:42AM +0200, Zdenek Salvet wrote:
> > > > On Wed, Aug 08, 2012 at 01:18:09PM +0000, Myklebust, Trond wrote:
> > > > > > 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.
> >
> > 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?
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.
On Thu, Aug 09, 2012 at 12:50:35PM -0400, J. Bruce Fields wrote:
> > 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.