4

I have two prgrams lets say prog1 and prog2. I am opening a file with prog1 and doing some operations on it. Now without closing the file in prog1 i am sending its file descriptor to prog2 using unix sockets which then does some operations in it.

Though i get the same descriptor i passed in prog1 but doing a fstat() on the fd recieved in prog2 throws an error saying Bad file descriptor. I have opened the file in prog1 with corerct permissions that is read and write for all, still i get an error.

Why is it happening so. If my way of passing a file descriptor is wrong then please suggest a correct one.

tnx123456
  • 125
  • 2
  • 8
  • 1
    I thought that file descriptors are belong to process. After you kill the process, file descriptors are gone. Am I wrong? – tartar Mar 28 '12 at 16:17
  • 1
    maybe you can make process 1 wait for the process 2 to finish its job. Then, they can die all together. – tartar Mar 28 '12 at 16:18
  • You can do what you're wanting, and it's fairly portable but not widely documented. I don't have the reference for how to do it on hand right now though. Anyway the answers so far are wrong... – R.. GitHub STOP HELPING ICE Mar 28 '12 at 18:03
  • i think running prog2 as a child process might be a better solution rather than try to share file descriptors. – tnx123456 Mar 28 '12 at 18:07
  • Passing file descriptors through a unix socket is a very nice technique, and complicated enough that it is really easy to mess it up. It is indeed possible that you have made a mistake in the manner in which you pass the descriptor, but it's hard to tell since you haven't shown us how you did it. – William Pursell Mar 28 '12 at 18:35
  • i agree. to be true i was not aware of the socketpair() and related functions that allows two different processes to share file descriptors. I was doing it the usual way. Now i will implement this method. Thanks everyone. – tnx123456 Mar 28 '12 at 18:41

3 Answers3

8

I believe this site has what you're looking for:

http://www.lst.de/~okir/blackhats/node121.html

There's also information in Linux's man 7 unix on using SCM_RIGHTS and other features of Unix sockets.

Fix for broken link: http://web.archive.org/web/20131016032959/http://www.lst.de/~okir/blackhats/node121.html

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
4

This is normal. Each program has its own file descriptors.

EDIT: Well, it seems that you can pass file descriptor using local socket.

You can see them in /proc/PID/fd, they are often symlinks to your files. What you can do with unix socket is allowing a write to a file from one program to another with sendmsg/recvmsg. See this question for more detail.

But there's way many better way to write concurrently to a file. You can use fifo, shm or even just pass your offset position between your 2 programs.

Community
  • 1
  • 1
Coren
  • 5,517
  • 1
  • 21
  • 34
2

A file descriptor is a small int value that lets you access a file. It's an index into a file descriptor table, a data structure in the kernel that's associated with each individual process. A process cannot do anything meaningful with a file descriptor from another process, since it has no access to any other process's file descriptor table.

This is for basic security reasons. If one process were able to perform operations on an open file belonging to another process, chaos would ensue. Also, a file descriptor just doesn't contain enough information to do what you're trying to do; one process's file descriptor 0 (stdin) might refer to a completely different file than another process's file descriptor 0. And even if they happen to be the same file, each process needs to maintain its own information about the state of that open file (how much it's read/written, etc.).

If you'll describe what you're trying to accomplish, perhaps we can help.

EDIT :

You want to pass data from one program to another. The most straightforward way to do this is to create a pipe (man 2 pipe). Note that the second process will have to be a child of the first.

An alternative might be to create a file that the second process can open and read (not trying to share a file descriptor), or you might use sockets.

Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
  • i will try to present my idea here.I am basically trying to implement on the fly decryption of encrypted data. My idea, which is wrong for sure, was to create prog1 which does the entire work related to decryption and prog2 simply sees data block which is un-encrypted and accesses it.Problem is that i want to allow only some authenticated processes to have access to it.For one the fly decryption i will be using fuse library.so i need say prog2 to authenticate to prog1 and then latter will decrypt it and pass some sort of link (fd,file pointer) to prog2 which can access it. – tnx123456 Mar 28 '12 at 17:31
  • This answer is somewhat incomplete, as unix domain sockets have an explicit ability to pass a "live" (as in usable) file descriptor between unrelated processes. It is not the integer value which gets passed (indeed it will likely be different on the recipient's side) but rather the conceptual "object" which it represents. – Chris Stratton Dec 10 '13 at 16:27