On Wed, Jun 5, 2024 at 11:37 AM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > Howdy - > > > On Jun 5, 2024, at 10:34 AM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > > > Hi Chuck, > > > > I noticed an interesting behaviour by the linux server. If I were to > > mount the linux server with vers=4.0,sec=sys,xprtsec=tls, acquire a > > delegation, and trigger a CB_RECALL, then it is done with gss > > integrity. Why is that? I thought callback is supposed to be done with > > the same security flavor as the forechannel. > > The CB_RECALL is using the same flavor and principal as was used > for the SETCLIENTID. That is all that the NFSv4.0 spec requires. Thanks. For some reason I thought "do state operations with krb5i was 4.1 thing and not 4.0". But I can see now that this started with the client doing SETCLIENTID using krb5i (even though mount was sec=sys). > Remember that xprtsec= does not specify a security flavor. > > > > But then also callback isn't done over TLS. Should the callback be > > done over TLS (and it's a future implementation to do for > > client/server)? > > The NFSv4.0 backchannel could be done over TLS, sure. > > > > Or is this a spec restriction/limitation? > > The NFSv4.0 spec doesn't know about TLS, so it doesn't take > a position about requiring it. > > Unless there's an interoperability concern, IMO standards action > isn't necessary. We can definitely say, though, that a prudent > NFSv4.0 server implementation would choose to try TLS if the > forward channel used it, and a prudent NFSv4.0 client would > require the use of TLS on the backchannel in that case. > > The Linux implementation does not do that yet -- TLS would > protect both directions of operation for NFSv4.1 and above, > but for NFSv4.0, it doesn't. Thank you for the clarification. Not sure it is worth the effort (given we've been discussing deprecating 4.0 anyway) but it answers my question if it's a question of implementation or spec. > > > -- > Chuck Lever > >
