Date: Wed, 1 Jul 2020 23:21:07 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Benjamin Kaduk <kaduk@mit.edu> Cc: Benjamin Kaduk <bjkfbsd@gmail.com>, Rick Macklem <rmacklem@FreeBSD.org>, src-committers <src-committers@freebsd.org>, "svn-src-projects@freebsd.org" <svn-src-projects@freebsd.org> Subject: Re: svn commit: r362798 - in projects/nfs-over-tls/sys/rpc: . rpcsec_tls Message-ID: <QB1PR01MB33645BA459A3A49C4C0AA8D4DD6C0@QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20200701225011.GH58278@kduck.mit.edu> References: <202006301449.05UEnq2x072917@repo.freebsd.org> <CAJ5_RoDe=_s2LZociYXTmdVOP%2BLJDA5HJ7jZkKr7LChffbaH8w@mail.gmail.com> <QB1PR01MB336441A427B14216A4A20384DD6F0@QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM> <20200630163340.GN58278@kduck.mit.edu> <QB1PR01MB3364FE7A60B953C2D730E6F3DD6C0@QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM> <QB1PR01MB33642D5CC58DF44548BB1911DD6C0@QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM> <20200701022040.GE58278@kduck.mit.edu> <QB1PR01MB336412382A4903F74CD28F69DD6C0@QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM>, <20200701225011.GH58278@kduck.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Benjamin Kaduk wrote:=0A=
>Rick Macklem wrote:=0A=
>> >Benjamin Kaduk wrote:=0A=
[stuff snipped]=0A=
>> >=0A=
>> >Can't you set a client-side (e.g., read) timeout, though?=0A=
>> Well, in this case it would be the read (or recv or ??) that is done ins=
ide the=0A=
>> SSL_connect().=0A=
>>=0A=
>> The timer I can control is the one that I had set to 10minutes, which ti=
mes out=0A=
>> the upcall RPC to the userland daemon. I had set it to 10minutes so the=
=0A=
>> SSL_connect() would time out first, but now that I know that won't alway=
s happen..=0A=
>> This timer is now set to 15sec and after it times out, the kernel code d=
oes a=0A=
>> soshutdown(so, SHUT_RD) in the client, which seems to be sufficient to g=
et=0A=
>> SSL_connect() to return an error.=0A=
>>=0A=
>> This seems sufficient and works ok for the testing I've done.=0A=
>=0A=
>I don't think what you ended up with is wrong, to be clear.=0A=
>=0A=
>But, you have an SSL* as input to SSL_connect(), and you can call=0A=
>SSL_get_fd() on that SSL*, which will give you a socket fd that you can=0A=
>call setsockopt() on, if you're so inclined. The SSL_connect() abstractio=
n=0A=
>barrier is not leak-proof :)=0A=
Well, actually in this case it is kind of the opposite..=0A=
- The kernel RPC creates a socket ("struct socket *", no file descriptor)=
=0A=
- The daemon does a rpctls_syscall() to acquire a file descriptor referenci=
ng=0A=
the socket during the connect upcall.=0A=
- The daemon does a SSL_set_fd() to tell the openssl library about the sock=
et=0A=
to use.=0A=
But, yes, the daemon does know what the socket file descriptor is.=0A=
=0A=
What you were suggesting was a setsockopt(so, SO_RCVTIMEO..) then?=0A=
=0A=
That would work too, I'd guess.=0A=
=0A=
I would have some reservations about doing it that way.=0A=
- I suspect the openssl library will always be prepared for a socket clos=
ure (EOF),=0A=
but I'm not so sure the library would expect a read failure with errno=
=3D=3D=0A=
EWOULDBLOCK. I'd have to look at the library sources and I'd also be=
=0A=
concerned that the situation might change w.r.t. this in the library.=
=0A=
=0A=
But if soshutdown(so, SHUT_RD) stops working, a setsockopt(so, SO_RCVTIMEO)=
=0A=
would certainly be an alternate approach.=0A=
=0A=
It is always a little scary when you are using a "black box" like the opens=
sl=0A=
libraries and doing somewhat unusual things.=0A=
=0A=
rick=0A=
=0A=
=0A=
> 15sec is pretty arbitrary, but I figure a timeout on the order of seconds=
is=0A=
> reasonable for RPC upcalls to the local daemon. (I'd guess that taking ev=
en=0A=
> 1sec to do an upcall would indicate something is broken.)=0A=
> If others feel 15sec isn't an appropriate timeout, feel free to comment.=
=0A=
> (Note that this timeout should only happen when something is broken, like=
=0A=
> the server that does a "STARTTLS" reply but does not do a TLS handshake.=
)=0A=
=0A=
Understood.=0A=
=0A=
Thanks,=0A=
=0A=
Ben=0A=
=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB33645BA459A3A49C4C0AA8D4DD6C0>