svn commit: r362798 - in projects/nfs-over-tls/sys/rpc: . rpcsec_tls

[Rick Macklem]

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