This is the mail archive of the
mailing list for the Cygwin project.
Re: Re:Done with passing file descriptors
- From: David E Euresti <davie at MIT dot EDU>
- To: <cygwin at cygwin dot com>
- Date: Tue, 18 Jun 2002 13:03:44 -0400 (EDT)
- Subject: Re: Re:Done with passing file descriptors
On Tue, 18 Jun 2002, Conrad Scott wrote:
> "David E Euresti" <davie@MIT.EDU> wrote:
> > So should I send my patch now or wait until I get a confirmation
> > from somebody?
> David, I've been following the discussion of the file descriptor
> passing (without following all the ins&outs and perhaps I too should
> go read up on it now in Stevens).
> I've been doing quite a bit of hacking in the cygserver code over the
> last week. What I've done so far is on the cygwin_daemon branch, which
> I will be submitting as a patch into HEAD in another few days. It
> would be good if we could synchronize this otherwise there's going to
> be some well-hairy merging going on. I'm about to commit another big
> dollop of changes into the branch (a gentle re-working of the
> client_request class). After that I'm unlikely to touch the non-shm
> parts of the cygserver code so I shouldn't disturb you after that. Of
> course, I could try to get my changes to this point back into HEAD
> now? I might send a message to cygwin-patches later on.
> I realise what I'm effectively doing is asking you to merge your code
> against my changes (rather than making me do it) and also asking you
> to depend on my non-HEAD changes. So, I wouldn't be offended if you in
> reply you sought to get your changes into HEAD before me. That's the
> fun of branches.
> Of course, others will have their views on this, to which mine are
> pretty subsidiary.
Hmmm. I don't know. I'm having enough problem contacting the CVS server in
general to get updates. Besides my code right now is in separate files and
I didn't do much in the way of modifying the cygserver, only use it. So
if you keep the interface the same, it really shouldn't be that bad.
> Oh, and BTW, I'm interested in seeing your code once you've submit it.
> I assume you've not got much in the way of security issues to worry
> about with what you're doing as long as the receiver can proof to
> cygserver that it is indeed the receiver of the file descriptors.
Actually right now, any rogue program could request any handle from the
cygserver and it will be given. I should probably fix this. Pass a nonce
or something, but that would require the cygserver to preserver state, and
I haven't seen how to do that yet.
> You'll also have a handle leakage problem with your current design.
> That is, if a client makes the initial request to cygserver in
> preparation for sending a file descriptor and then that process dies,
> cygserver has already duplicated the handles and can't know whether it
> should keep them or not since the message may or may not have been
> sent to the receiving client via the socket. The same is true if the
> receiver dies between receiving the message from the socket and asking
> cygserver to duplicate the handle for it.
> I'm unclear what can be done about this, short of a horrendously
> complicated protocol, but it makes the system rather fragile, since
> there could be handles held onto indefinitely by cygserver, and thus
> objects can't be deleted etc. Any thoughts? or have I missed
No you haven't missed anything. Handle leakage when a process dies is a
serious problem. Without knowing the destination of the handle it's kind
of hard to tell when that process will die.
One idea is to set a timer on each handle, and when the timer expires, the
handle can disappear. Of course we'd have to set a decent sized timer,
and if a process is very slow it may not read it. So we'd be solving the
problem using an assumption that may not be correct. (And that's bad)
> Looking forward to thinking some more about this :-)
> // Conrad
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html