From: David E Euresti <davie@MIT.EDU>
To: egor duda <cygwin@cygwin.com>
Subject: Re: Duplicating Unix Domain Sockets
Date: Tue, 04 Jun 2002 08:07:00 -0000 [thread overview]
Message-ID: <Pine.GSO.4.30L.0206041039490.745-100000@scrubbing-bubbles.mit.edu> (raw)
In-Reply-To: <291438343308.20020604101630@logos-m.ru>
On Tue, 4 Jun 2002, egor duda wrote:
> Hi!
>
> It's not enough to just pass numerical value of descriptor between
> processes. Each cygwin fd has several win32 handles associated with
> it, which are used to actually do the job, to read or write the data,
> to perform synchronization, etc. If you want to pass fd1 from proc1 to
> proc2, you have to duplicate all win32 handles associated with fd1
> into address space of proc2. This can be done by DuplicateHandle ()
> function, but if you take a look on its docs on msdn, you'll see that
> it requires process handles of proc1 and proc2 to work. Given that
> proc1 and proc2 can be absolutely unrelated and run from different
> accounts, there's no secure way to obtain those process handles
> without help from some mediator process which run at high enough level
> of privileges.
Oh I know it's not enough just passing a number. I've already got a user
land application passing file descriptor by passing
struct passfd {
unsigned int uiMagic; // Magic number to see if it's right
DWORD dwProcessID; // Process ID of sender
HANDLE hHandle; // Handle in sender's process
BOOL bBinary; // is it Binary or Text?
BOOL bRead; // Is it read?
BOOL bWrite; // Is it write
DWORD dwDevice; // Device type as listed in windows_device_names
in path.cc
};
So basically I pass this info in at the beginning of a packet. And then
the receiving end calls DuplicateHandle, followed by cygwin_handle_to_fd.
It works well except it doesn't mark the right socket types. i.e. UDP,
TCP, AF_UNIX etc. (I've sent the code before search for my name in the
archive and you'll find it titled "File Descriptor passing fun".
Another problem with this is that there's a bit of synchronization needed
because the sending process can't close the socket until it's been
duplicated. This will actually happen in the suggestion I had.
> That's what cygwin daemon is for -- to provide a
> services that require high privileges to normal non-privileged
> processes. After such handle duplication service (with appropriate
> security checks) is implemented in cygwin daemon, it would be simple
> to augment AF_UNIX sockets protocol to be able to pass auxiliary
> information such as fds.
>
Well as I have to have this to graduate, I could work on this. But
somebody needs to tell me where to start looking. Because i've looked
through the source and I don't really get it.
Thanks,
David
--
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/
next prev parent reply other threads:[~2002-06-04 15:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-03 13:52 David E Euresti
2002-06-03 13:59 ` Christopher Faylor
2002-06-03 23:17 ` egor duda
2002-06-04 5:41 ` Robert Collins
2002-06-05 12:30 ` David E Euresti
2002-06-04 8:07 ` David E Euresti [this message]
2002-06-04 8:33 ` egor duda
2002-06-04 8:40 ` David E Euresti
-- strict thread matches above, loose matches on Subject: below --
2002-06-03 15:19 David E Euresti
2002-06-03 17:01 ` Bob Friesenhahn
2002-06-03 12:37 David E Euresti
2002-06-03 12:42 ` Christopher Faylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.GSO.4.30L.0206041039490.745-100000@scrubbing-bubbles.mit.edu \
--to=davie@mit.edu \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).