certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] RFC: avoid racy sleep to establish connection to rtia


From: Mathias Fröhlich
Subject: Re: [certi-dev] RFC: avoid racy sleep to establish connection to rtia
Date: Tue, 11 Aug 2009 18:05:21 +0200
User-agent: KMail/1.11.4 (Linux/2.6.27.29-170.2.78.fc10.x86_64; KDE/4.2.4; x86_64; ; )

Hi,

On Monday 10 August 2009 21:59:42 Eric Noulard wrote:
> > * On win32 the connection is still done by a local tcp socket, but for
> > this case the role of the server and client is reversed to avoid the race
> > condition. The application is acting as the server and the rtia process
> > connects to the listening server socket in the application.
>
> This may be a security breach, because RTIA used to be a trusted process,
> for which you can authorize server port listening. The situation is not
> that good if we make the server reside in the application,
> but may be we can live with it, this has to be discussed.
Hmm, ok. I did not think about that.
I was first looking for an emulation of the socketpair call we usually have on 
unix. But the only emulation that really worked well was one that actually 
does the same than the current patch does - except that this is done from 
within the same binary. But then I had to inherit the filedescriptor across the 
create process call.
I am not sure if the firewall rules also apply when the listen/accept happens 
in the same process than the connect?
Also is there some network address that is trusted in any case?
Or do we have any other mechanism to have a socket like connection between two 
processes on win32 without the need of a whole in the firewall?
Open to all suggestions ...

> > * The TCP port number does no longer default to the process id which
> > should eliminate some possible failures due to process id's that are
> > equal to already occupied port numbers.
>
> Ok, then I'll see how you did it in your patch.
Just bind at a anonymous address and ask in the next step which port you got. 
This is the standard way with the BSD api to handle that.

> > Please include that changes with the next release of certi or tell me
> > what I need to do to get that or something similar into certi.
>
> I'll review your patch and then tell you more about it.
> Note that the usual way to submit a patch is to create
> a new entry in the patch tracker:
> https://savannah.nongnu.org/patch/?group=certi
Ok. Will register there.

> Announcing the provided patch on the ML is good too in order to make
> the community aware of it. Admin and interested CERTI dev do already
> get notification for each new bug/patches, but adding an explaining message
> on the list pointing to the supplied patch tracker entry is good too.
>
> May be you can already add your patch to the patch tracker?
Ok.

Greetings

Mathias




reply via email to

[Prev in Thread] Current Thread [Next in Thread]