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>
index | next in thread | previous in thread | raw e-mail
Benjamin Kaduk wrote:
>Rick Macklem wrote:
>> >Benjamin Kaduk wrote:
[stuff snipped]
>> >
>> >Can't you set a client-side (e.g., read) timeout, though?
>> Well, in this case it would be the read (or recv or ??) that is done inside the
>> SSL_connect().
>>
>> The timer I can control is the one that I had set to 10minutes, which times out
>> the upcall RPC to the userland daemon. I had set it to 10minutes so the
>> SSL_connect() would time out first, but now that I know that won't always happen..
>> This timer is now set to 15sec and after it times out, the kernel code does a
>> soshutdown(so, SHUT_RD) in the client, which seems to be sufficient to get
>> SSL_connect() to return an error.
>>
>> This seems sufficient and works ok for the testing I've done.
>
>I don't think what you ended up with is wrong, to be clear.
>
>But, you have an SSL* as input to SSL_connect(), and you can call
>SSL_get_fd() on that SSL*, which will give you a socket fd that you can
>call setsockopt() on, if you're so inclined. The SSL_connect() abstraction
>barrier is not leak-proof :)
Well, actually in this case it is kind of the opposite..
- The kernel RPC creates a socket ("struct socket *", no file descriptor)
- The daemon does a rpctls_syscall() to acquire a file descriptor referencing
the socket during the connect upcall.
- The daemon does a SSL_set_fd() to tell the openssl library about the socket
to use.
But, yes, the daemon does know what the socket file descriptor is.
What you were suggesting was a setsockopt(so, SO_RCVTIMEO..) then?
That would work too, I'd guess.
I would have some reservations about doing it that way.
- I suspect the openssl library will always be prepared for a socket closure (EOF),
but I'm not so sure the library would expect a read failure with errno ==
EWOULDBLOCK. I'd have to look at the library sources and I'd also be
concerned that the situation might change w.r.t. this in the library.
But if soshutdown(so, SHUT_RD) stops working, a setsockopt(so, SO_RCVTIMEO)
would certainly be an alternate approach.
It is always a little scary when you are using a "black box" like the openssl
libraries and doing somewhat unusual things.
rick
> 15sec is pretty arbitrary, but I figure a timeout on the order of seconds is
> reasonable for RPC upcalls to the local daemon. (I'd guess that taking even
> 1sec to do an upcall would indicate something is broken.)
> If others feel 15sec isn't an appropriate timeout, feel free to comment.
> (Note that this timeout should only happen when something is broken, like
> the server that does a "STARTTLS" reply but does not do a TLS handshake.)
Understood.
Thanks,
Ben
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB33645BA459A3A49C4C0AA8D4DD6C0>