Re: [Chicken-hackers] Problem with OpenSSL and file descriptors (sendfile)

[Felix]

From: Peter Bex <address@hidden>
Subject: [Chicken-hackers] Problem with OpenSSL and file descriptors (sendfile)
Date: Sat, 3 Jul 2010 22:24:38 +0200

> 
> Now, it turns out that openssl's ssl-accept stores the raw file
> descriptors it receives from the underlying call to tcp-accept in
> the input and output ports it creates.  This means that when you use
> the nice Scheme port abstraction everything will be fine; it uses
> SSL_write() when you write to the port, causing the data to be wrapped
> in SSL protocol stuff.  However, when you extract the descriptor using
> port->fileno, you get the raw TCP descriptor and when you write
> something to that, you screw up the SSL protocol conversation.
> 
> Now, I commented out the setslot lines in openssl.scm and sure enough,
> sendfile on a SSL port works fine again.  It's of course not able to
> use the fastest implementation because the output needs to go through
> openssl, but at least the abstraction doesn't fail and Spiffy can use
> HTTPS transparently without a lot of port checking cruft.
> 
> However, this breaks many other things; for example, when a request
> comes in Spiffy logs the incoming request with the IP address of the
> remote side.  This uses tcp-addresses, which expects a TCP port with
> a file descriptor slot.
> 
> I think the clean way to solve this is not to use the file descriptor
> slot as this isn't supposed to be written to with SSL, but some other
> slot (?), and then provide ssl equivalents to all TCP operations that
> would no longer work when we do that.  This has already been done
> for the operations on listeners.
> 
> I don't know if that's possible; how to know what slot is valid and
> available for these ports, and that no other code uses this slot?
> 

Ugh - another dark and dirty part of the core libraries. The slots
in port-records are used in a pretty inconsistent manner: there
are reserved slots and "port-data" and it's all just a horrible 
mess (BTW, thanks to Kon for pointing out just exactly such a case
recently - I write this here because all my replies bounce. Well,
who cares anyway? Boy, it's so hot in here ...).

So... You could use the "reserved" fields (you actually *should* use
the "port-data", but some silly implementor (me) has already broken
this convention), so you could use the "reserved" fields of the port
(see around line 1630 in library.scm) to store whatever you want, just
make sure both tcp.scm and openssl.scm agree on their use.  The
port-type (whether it refers to a socket or not, which is possible
what you need as well) is in slot #7.

Hm. It would probably be a good idea to use symbolic names instead of
slot numbers. On the other hand, this is just too low-level anyway, so
you deserve nothing better. ssl-make-i/o-ports should simply not
modify the port-data. Very bad. Verboten. Absolutely.


cheers,
felix