Mail Archives: cygwin-apps/2001/06/18/02:51:50
Hi!
Monday, 18 June, 2001 Robert Collins robert DOT collins AT itdomain DOT com DOT au wrote:
>> BTW, Ralf, are those sockets that fail in you test work in blocking or
>> non-blocking mode?
RC> Egor, I've been trying to grok the code. Can you tell me if I've got
RC> this right?
RC> on bind() you create a cookie and write it to the file. You also create
RC> a event with a name related to the cookie.
RC> on connect() you read the file and attempt to open the previously
RC> created event. A failure to open is used to indicate failure.
not quite. both peers (one that's accept()ing and one that's
connect()ing)) open theirs own events, and wait until they're
signalled. both also open their respective peer's event and signal it.
see http://sources.redhat.com/ml/cygwin-apps/2001-06/msg00063.html for
details.
RC> I ask because I've been playing around with this on win2k sp1, ntsec on.
RC> With XFree86 I get a "inode has changed" error on the /tmp/.X11-unix/foo
RC> socket. Removing the .X11-unix directory fixes that. I suspect it's
RC> related to problem Ralf is describing.
do this problem persists if you run everything's with
'strace -b 65000 -f -o strace.log your_program.exe'
?
if so, what does 'grep "unauthorized" strace.log'
prints after that?
RC> Anyway back to the AF_UNIX sockets - two questions:
RC> 1) what stops someone using the NT namespace to see the available events
RC> with a name format like the secure socket event names?
you can't just "browse" all existing events, unless you're admin. to
open event you have to know (or guess) its name.
RC> 2) Why not allow the accept() to happen at the win32 level, but read and
RC> write the cookie between cygwin, before letting the user program know
RC> that cygwin is involved? It seems to me that that would be a somewhat
RC> easier solution.
i'm not sure i understand what you mean here.
Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19
- Raw text -