Re: Re:Done with passing file descriptors

[David E Euresti <davie at MIT dot EDU>]

Hello,

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
> something?

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
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/