Re: Duplicating Unix Domain Sockets

Re: Duplicating Unix Domain Sockets

[David E Euresti]

Allright.  So I have two solutions.
(And tell me if I should direct this to the folks at cygwin-devel)

#1
Make cygwin be able to implement the Ancillary data as in 4.3+BSD as
described in section 15.3.3 in Advanced Programming in the Unix
Environment.

To implement this, I would tag all messages sent on Unix domain sockets
with a tag like this:
struct tag {
	int adatalen; // Length of ancillary data
	int rdatalen; // Length of real data
}

Then when you receive it your first read the tag and if there is ancillary
data read it and do what you need to do (convert the info into an fd) and
then read the rdatalen.  If there is more rdatalen than the length of
buffer sent to you, you return what you can, and remember how much is
left.

This is obviously a big task, and opinions would be quite welcome.

#2
Just add a function that says, create_fd_from_handle_plus were I can
pass in all the parameters that the sending process could send, and so
that the same file descriptor gets created.  The problem with this is that
getting the info from one process to another (IPC?) is up to the
programmer.

As you can tell I really want to pass file descriptors between cygwin
processes.  I think from a networking standpoint it's useful.  Now for all
I know somebody else has done this already (possibly doing something
easier), please let me know.

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/

Re: Duplicating Unix Domain Sockets

[Christopher Faylor]

On Mon, Jun 03, 2002 at 04:47:49PM -0400, David E Euresti wrote:
>Allright.  So I have two solutions.
>(And tell me if I should direct this to the folks at cygwin-devel)
>
>#1
>Make cygwin be able to implement the Ancillary data as in 4.3+BSD as
>described in section 15.3.3 in Advanced Programming in the Unix
>Environment.
>
>To implement this, I would tag all messages sent on Unix domain sockets
>with a tag like this:
>struct tag {
>	int adatalen; // Length of ancillary data
>	int rdatalen; // Length of real data
>}
>
>Then when you receive it your first read the tag and if there is ancillary
>data read it and do what you need to do (convert the info into an fd) and
>then read the rdatalen.  If there is more rdatalen than the length of
>buffer sent to you, you return what you can, and remember how much is
>left.
>
>This is obviously a big task, and opinions would be quite welcome.

Sounds like it would slow down every UNIX domain socket read.

I'll let Egor comment on this, though.  It's his code.

cgf

--
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/

Re: Duplicating Unix Domain Sockets

[egor duda]

Hi!

Tuesday, 04 June, 2002 David E Euresti davie@MIT.EDU wrote:

DEE> Allright.  So I have two solutions.
DEE> (And tell me if I should direct this to the folks at cygwin-devel)

I believe most, if not all subscribers of cygwin-developers@ are
reading cygwin@ mailing list.

DEE> #1
DEE> Make cygwin be able to implement the Ancillary data as in 4.3+BSD as
DEE> described in section 15.3.3 in Advanced Programming in the Unix
DEE> Environment.

DEE> To implement this, I would tag all messages sent on Unix domain sockets
DEE> with a tag like this:
DEE> struct tag {
DEE>         int adatalen; // Length of ancillary data
DEE>         int rdatalen; // Length of real data
DEE> }

DEE> Then when you receive it your first read the tag and if there is ancillary
DEE> data read it and do what you need to do (convert the info into an fd) and
DEE> then read the rdatalen.  If there is more rdatalen than the length of
DEE> buffer sent to you, you return what you can, and remember how much is
DEE> left.

DEE> This is obviously a big task, and opinions would be quite welcome.

DEE> #2
DEE> Just add a function that says, create_fd_from_handle_plus were I can
DEE> pass in all the parameters that the sending process could send, and so
DEE> that the same file descriptor gets created.  The problem with this is that
DEE> getting the info from one process to another (IPC?) is up to the
DEE> programmer.

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. 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.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
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/

RE: Duplicating Unix Domain Sockets

[Robert Collins]

> -----Original Message-----
> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of egor duda


> 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.

And as the daemon's features for handle passing are complete (the tty
code works fine), this should be easily achievable now. I don't have
time myself, but will happily provide pointers for anyone wanting to add
the necessary code to the cygserver.

Rob


--
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/

RE: Duplicating Unix Domain Sockets

[David E Euresti]

Hello,
	Ideas about how to use the cygserver below.  Please comment.

On Tue, 4 Jun 2002, Robert Collins wrote:

>
>
> > -----Original Message-----
> > From: cygwin-owner@cygwin.com
> > [mailto:cygwin-owner@cygwin.com] On Behalf Of egor duda
>
>
> > 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.
>
> And as the daemon's features for handle passing are complete (the tty
> code works fine), this should be easily achievable now. I don't have
> time myself, but will happily provide pointers for anyone wanting to add
> the necessary code to the cygserver.
>
> Rob


I tried to follow the code and I see that it calls Duplicate socket and
all that good stuff.
So here's the procedure as it currently works on Unix:

sender: Call sendmsg() with msghdr filled in.
receiver: Call recvmsg(), suddenly the msghdr has a file descriptor

Here are some assumptions that have to be used.
#1 The sending procedure doesn't know about the other side of the socket.
It could be a socketpair followed by a fork, or a unix socket on /tmp or
something like that.
#2 The receiving procedure doesn't know where the socket is coming
from it's coming from.
#3 There may be multiple processes trying to pass multiple file
descriptors at the same time.

So here's what I'm thinking the cygserver could do.
On a call to sendmsg() with the msghdr filled in, get the file
descriptor, extract enough information to duplicate it.  Call into
cygserver saying WriteFileDescriptor or something like that with all this
info.

The cygserver grabs it, duplicates the Handle, and stashes it away.

The receiver calls RecvMsg and in the process calls the cygserver
ReadFileDescriptor, now there may or may not be a descriptor waiting for
it.  If there is then it duplicates the handle, and creates a file
descriptor for it.

Now the big problem is how the cygserver will tell where the destination
of the file handle is.  I think, mind I say I think, that this could be
solved by calling into getpeername, but I'm not certain.

Another problem is how to tell the cygserver, and how the cygserver will
tell us, that the handle has been duplicated and we can close the handle.
(We don't want to leave stray handles flying around)

Unfortunately this means that the cygserver needs to be running for all
apps that want to use Unix domain sockets.

Comments?

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/

Re: Duplicating Unix Domain Sockets

[David E Euresti]

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/

Re: Duplicating Unix Domain Sockets

[egor duda]

Hi!

Tuesday, 04 June, 2002 David E Euresti davie@MIT.EDU wrote:

>> 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.

DEE> Oh I know it's not enough just passing a number.  I've already got a user
DEE> land application passing file descriptor by passing

Who's filling this structure? If it's sender, then it won't work as
hHandle has no meaning in receiver. If receiver fills the structure
then i can't see how normal non-privileged user process can get handle
of other process possibly running from other account. Even if you
manage to make it happen, that'd open a security hole -- you'll allow
receiver to access sender's address space.

DEE> struct passfd {
DEE>   unsigned int uiMagic;  // Magic number to see if it's right
DEE>   DWORD dwProcessID;     // Process ID of sender
DEE>   HANDLE hHandle;        // Handle in sender's process
DEE>   BOOL bBinary;          // is it Binary or Text?
DEE>   BOOL bRead;            // Is it read?
DEE>   BOOL bWrite;           // Is it write
DEE>   DWORD dwDevice;        // Device type as listed in windows_device_names
DEE> in path.cc
DEE> };

DEE> So basically I pass this info in at the beginning of a packet.  And then
DEE> the receiving end calls DuplicateHandle, followed by cygwin_handle_to_fd.
DEE> It works well except it doesn't mark the right socket types.  i.e. UDP,
DEE> TCP, AF_UNIX etc.  (I've sent the code before search for my name in the
DEE> archive and you'll find it titled "File Descriptor passing fun".

DEE> Another problem with this is that there's a bit of synchronization needed
DEE> because the sending process can't close the socket until it's been
DEE> 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.
>>

DEE> Well as I have to have this to graduate, I could work on this. But
DEE> somebody needs to tell me where to start looking.  Because i've looked
DEE> through the source and I don't really get it.

Handle duplication code is present in cygserver.cc. It wasn't
originally designed to pass fds via AF_UNIX sockets, so security
checks in it may be not what's needed here. What you have to do is to
pass (via whatever mechanism you like) all win32 handles assosiated
with particular fd and then make receive ask cygwin daemon to perform
handle duplication via request similar to CYGSERVER_REQUEST_ATTACH_TTY

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
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/

Re: Duplicating Unix Domain Sockets

[David E Euresti]

Hello,

On Tue, 4 Jun 2002, egor duda wrote:

> Hi!
>
> Tuesday, 04 June, 2002 David E Euresti davie@MIT.EDU wrote:
>
> Who's filling this structure? If it's sender, then it won't work as
> hHandle has no meaning in receiver. If receiver fills the structure
> then i can't see how normal non-privileged user process can get handle
> of other process possibly running from other account. Even if you
> manage to make it happen, that'd open a security hole -- you'll allow
> receiver to access sender's address space.

The sender is filling in the structure.  And you're right hHandle has no
meaning to the receiving process, except that it does have meaning to
DuplicateHandle,

From MSDN:
BOOL DuplicateHandle(
  HANDLE hSourceProcessHandle,  // handle to the source process
  HANDLE hSourceHandle,         // handle to duplicate
  HANDLE hTargetProcessHandle,  // handle to process to duplicate to
  LPHANDLE lpTargetHandle,  // pointer to duplicate handle
  DWORD dwDesiredAccess,    // access for duplicate handle
  BOOL bInheritHandle,      // handle inheritance flag
  DWORD dwOptions           // optional actions
);

hSourceHandle
Handle to duplicate. This is an open object handle that is valid in the
context of the source process.

So the sending process says, I'm process X, the handle (in my process) is
Y, and the receiver calls DuplicateHandle with (X, Y, MyProcess,
&MyHandle, etc.)  And then you have your duplicated socket handle.  It's
all Kernel magic I believe.

>
> DEE> struct passfd {
> DEE>   unsigned int uiMagic;  // Magic number to see if it's right
> DEE>   DWORD dwProcessID;     // Process ID of sender
> DEE>   HANDLE hHandle;        // Handle in sender's process
> DEE>   BOOL bBinary;          // is it Binary or Text?
> DEE>   BOOL bRead;            // Is it read?
> DEE>   BOOL bWrite;           // Is it write
> DEE>   DWORD dwDevice;        // Device type as listed in windows_device_names
> DEE> in path.cc
> DEE> };
>

>
> Handle duplication code is present in cygserver.cc. It wasn't
> originally designed to pass fds via AF_UNIX sockets, so security
> checks in it may be not what's needed here. What you have to do is to
> pass (via whatever mechanism you like) all win32 handles assosiated
> with particular fd and then make receive ask cygwin daemon to perform
> handle duplication via request similar to CYGSERVER_REQUEST_ATTACH_TTY
>
Currently looking at this.

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/

Re: Duplicating Unix Domain Sockets

[David E Euresti]

I'm not so sure that it'll make it that much slower. I mean we are talking
of adding only a couple of bytes to every send Unix Domain sockets.  And
Unix domain sockets never go outside the computer.  Obviously it'll hurt
if your program usually sends small packets, but you'll gain in being able
to pass file descriptors through there.

But I would like to hear what the original developer has to say.

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/

Re: Duplicating Unix Domain Sockets

[Bob Friesenhahn]

On Mon, 3 Jun 2002, David E Euresti wrote:

> I'm not so sure that it'll make it that much slower. I mean we are talking
> of adding only a couple of bytes to every send Unix Domain sockets.  And
> Unix domain sockets never go outside the computer.  Obviously it'll hurt

Given that the implementation of Unix domain sockets normally pass
womping 108 byte path strings (see Richard W.  Stephens TCP/IP
Illustrated Volume 3 or the 'sockaddr_un' structure) with each message
a few extra bytes of overhead won't matter very much.

> if your program usually sends small packets, but you'll gain in being able
> to pass file descriptors through there.

Small packets are likely to be smaller than the address. :-)

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen


--
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/

Duplicating Unix Domain Sockets

[David E Euresti]

Hello,
	So I've been working on this passing file descriptor between
processes thing. And I've gotten something that works well.  I'm using
cygwin_attach_handle_to_fd to create the file descriptor.  Unfortunately I
can't seem to see how to create a Unix Domain socket (AF_UNIX) using this.
I've traced through all the source and can't seem to find the place to do
it.

	I've also heard talk that the cygserver can be used to pass file
descriptors.  But I can't find the information to do 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/

Re: Duplicating Unix Domain Sockets

[Christopher Faylor]

On Mon, Jun 03, 2002 at 03:36:56PM -0400, David E Euresti wrote:
>Hello,
>	So I've been working on this passing file descriptor between
>processes thing. And I've gotten something that works well.  I'm using
>cygwin_attach_handle_to_fd to create the file descriptor.  Unfortunately I
>can't seem to see how to create a Unix Domain socket (AF_UNIX) using this.
>I've traced through all the source and can't seem to find the place to do
>it.

cygwin_attach_handle_to_fd is an interface intended for use with a user-level
program that wants to associate an existing *windows handle* with a cygwin fd.

If you are trying to add functionality to cygwin to allow fd passing
then you shouldn't be using this function.  It is not intended for use
with cygwin-specific things like unix-domain-sockets.  Those really
exist only in the cygwin domain and they are already associated with an
fd.

If you are attempting to do this as a user program rather than as a modification
to the cygwin DLL, then you are probably out-of-luck.

cgf

--
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/