Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Tue, 18 Jun 2002 13:03:44 -0400 (EDT) From: David E Euresti To: Subject: Re: Re:Done with passing file descriptors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, On Tue, 18 Jun 2002, Conrad Scott wrote: > > > "David E Euresti" 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/