On 21 November 2010 15:25, Ben Kibbey <bjk_at_luxsci.net> wrote:
> On Sun, Nov 21, 2010 at 01:48:45PM +0000, Alexander Lamaison wrote:
>> > Is it only the FILE* structure? What about the file descriptor of the
>> > opened stream obtained from fileno(3)? Is that safe?
>>
>> Also not safe.
>>
>> Unfortunately, as far as I'm aware, every file operation manipulates
>> internal tables so you can never safely use any form of opened file
>> descriptor across API calls.
>
> I'm sorry if I'm asking the same question, but what about a file
> descriptor returned from open(2)? The data structures rely on the OS
> rather than libraries don't they?
On Windows, at least, open() is provided by the C-runtime therefore
subject to all the earlier caveats. On Linux it appears that open()
can be provided by the C-runtime or directly as a system call
depending on how you link but I'm not sure about this. Basically, you
can't rely on it being a system call on all platforms.
I find your problem interesting and it's not one I've considered
before: where you have to pass an opened file for security, to prevent
a third-party hijacking the filename. The only safe solution I can
think of is to add a call to libssh2 that takes the knownhosts file as
a buffer in memory. Then you can read it in yourself and just pass
the buffer across the API call. We already do this
libssh2_userauth_publickey(), for instance.
Alex
P.S. What I said earlier about still having some uses of FILE* in the
API isn't true. There are none :) I was getting confused with
libssh2's use of OpenSSL which used to use some of OpenSSL FILE* APIs.
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-11-21