File D escriptor Passing without sockets or streams - possible ?

[jeyte]

Hello Forum,

i have a problem passing a file descriptor from one process to another.

I have two processes A and B. Both are running in different network and
filesystem namespaces, so it is impossible to use unix domain sockets or
net sockets to pass a file descriptor from process A to process B.

The usage of STREAMS is also impossible, as you can see in
fixunix.com/unix/84093-streams-pipes-ioctl-i_sendfd.html

[quotation begin]
Linux doesn't have STREAMS, which are the System V way
of doing this task. ...
[quotation end]

Are there additional possibilities for file descriptor passing like
using named pipes or something like that or does anybody know
a good workaround for this problem ?

Thank you very much !!
Julian

[ultimatelinux]

I think using named pipe is also going to be a difficult thing since they are on network.

[jeyte]

In R.Stevens (Advanced Progamming in the UNIX Environmnent) there are explained two possibilities for passing file descriptors.

The first possibility is passing file descriptors over UNIX domain sockets. For this reason sendmsg() and recvmsg() are used.

The second possiblility is passing file descriptors over STREAMS-Based Pipes using ioctl(). This possibility does't work for Linux, because it doesn't support STREAMS-Based Pipes. There are some libraries like openss7, which add this functionality but i want to avoid this (if possible )

[Schmidt]

Emm... As I remember, file descriptors are just integer numbers, unique for each process, am I right?... Then I suppose we should pass contents of a file, not its identifier, 'cause descriptor will not have much sense to another process, if we are not using shared memory... Then, what a problem is?... Just use TCP/IP..

[jeyte]

Tank you for your answer !!

As I remember, file descriptors are just integer numbers, unique for each process, am I right?

... yes thats right. In my case the usage of TCP/IP sockets is not possible because process B runs in another network namespace than process A - in terms of networking a server program (process A) is invisble for a client program (process B).

[Schmidt]

As I understood, the programm-receiver does not have a tcp socket?... Then you can just write a 'middle-man', that will be listen tcp socket on machine where programm-receiver runs, and pass data to it through pipe, for example. There are no ways to pass data over the network without using any kinds of sockets

[jeyte]

As I understood, the programm-receiver does not have a tcp socket?... Then you can just write a 'middle-man', that will be listen tcp socket on machine where programm-receiver runs, and pass data to it through pipe, for example. There are no ways to pass data over the network without using any kinds of sockets

Unfortunately i must do it without networking at all.

The situation is as follows:



Root NS - Server -------(unshare())-----> Child NS - Client



The server process runs in Root network namespace. After an unshare system call a child namespace will be created, which has only a loopback interface and the networking of the Root NS is invisible for the Client.
That means that all network sockets and unix domain sockets of Root NS aren't accessible in Child NS. If you want f.e. access to /dev/log in the Child NS, this doesn't work because of the unix domain socket isolation.
To solve this problem, a descriptor opened by the Server in Root NS must be passed to the Client.
F.e the server opens /dev/log and passes the filedescriptor to the client which can now access /dev/log over the passed file descriptor.
The central problem is the medium for file descriptor passing. I can not use TCP/IP sockets because of the network isolation (unshare()) and i can not use unix domain sockets because of the unix domain socket isolation.

Because of this, the IPC between Server and Client must be done in another way. For example a named pipe.
But i don't know if file descriptor passing using named pipes is possible.

Thank you !!

[igc35]

Do you have to use the same file descriptor? If the 2 processes share nothing then there doesn't seem to be any point. Just open the same file by name in each process. I presume the server process can access the client filesystem.

If you need to pass something between the processes, write it to a common, known file. (You might be able to pass the FD this way too, but as above I doubt it buys you anything.)

It will be up to you to manage your own locking etc.

[Schmidt]

Unfortunately i must do it without networking at all.

The situation is as follows:



Root NS - Server -------(unshare())-----> Child NS - Client



The server process runs in Root network namespace. After an unshare system call a child namespace will be created, which has only a loopback interface and the networking of the Root NS is invisible for the Client.
That means that all network sockets and unix domain sockets of Root NS aren't accessible in Child NS. If you want f.e. access to /dev/log in the Child NS, this doesn't work because of the unix domain socket isolation.
To solve this problem, a descriptor opened by the Server in Root NS must be passed to the Client.
F.e the server opens /dev/log and passes the filedescriptor to the client which can now access /dev/log over the passed file descriptor.
The central problem is the medium for file descriptor passing. I can not use TCP/IP sockets because of the network isolation (unshare()) and i can not use unix domain sockets because of the unix domain socket isolation.

Because of this, the IPC between Server and Client must be done in another way. For example a named pipe.
But i don't know if file descriptor passing using named pipes is possible.

Thank you !!

then, I do not understand... You said that these processes run "in different networks and different filesystems". Then, I supposed that there are two different machines, is it right or not?... Any IPC on a single machine is quite simple - if you want to share a file, just open it by name in each process. So what do we have - one or two machines?..

[unlimitedscolobb]

Unfortunately i must do it without networking at all.

If you have different machines, I'm afraid you cannot make them communicate without having any kind of networking (unless you consider using USB flash drives ). So, I'd suppose the OP means that the two processes are located on the same machine, but the files they try to access are in different filesystems, in which case what Schmidt and igc35 suggest is the solution, unless of course the child is not allowed to access the "Root NS" filesystem. In that case the "middle-man" (running with sufficient priveleges to access both "Root NS" and "Child NS") suggested by Schmidt is the only (apparent) solution.

Because of this, the IPC between Server and Client must be done in another way. For example a named pipe.
But i don't know if file descriptor passing using named pipes is possible.

As Schmidt says, file descriptors are just binary data, so if you manage to setup a name pipe, you will be able to pass one. However, this makes very little sense if your processes really have access to different filesystems.