How to find in child process what message queues, sempahores and device files are opened by parent process?

Hi, In my code am forking child process and doing execv("/bin/sh", argv) to execute commands. Parent process waits on the child process till command is executed. Child process inherits the open file descriptors, open message queues and sempahores, am not using these in child process and would like to close them. Is there a way to find what all message queues, sempahores and files are opened by parent process? And is there any other side effect in leaving inherited fd's opened apart from buggy child process writing to any of the parent fd's ? Thanks, Mushtaq Khan

khan <mushtaqk921@gmail.com> wrote: > In my code am forking child process and doing execv("/bin/sh", argv) > to execute commands. Parent process waits on the child process till > command is executed. > Child process inherits the open file descriptors, open message queues > and sempahores, am not using these in child process and would like to > close them. > Is there a way to find what all message queues, sempahores and files > are opened by parent process? well, the child process is (more or less) an exact copy of the parent process, so it knows what it has open as much as the parent process does. If you want to have all files closed then I would think setting the close-on-exec flag on all files you open (see the section about file descriptor flas in the fcntl(3) man page, you will have to set FD_CLOEXEC). This will result in all files for which this flag is set to become closed auto- matically when one of the functions of the exec-family is invoked. Of course, some files may have been opened by a library that you don't have control over and, unfortunately, many libraries don't set FD_CLOEXEC on files they open. In that case you will have to resume to using platform dependent methods, e.g. under Linux you could scan /proc/self/fd for open file descriptors. In the case of message queues and semaphores you probably will have to know what you've opened, I don't know a way to get from the kernel a list of all processes that have them open. > And is there any other side effect in leaving inherited fd's opened > apart from buggy child process writing to any of the parent fd's ? A buggy application could indeed try to write to a file descriptor it never opened and thus accidentally "hit" an open file it inherited, so closing all files before callinhg exec() might be prudent. Other serious problems I can't see at the moment. Problems due to semaphores and message queues would seem at me to be a lot less of an issue since you need to know the key for that resource to be able to use it and a com- pletely unrelated program would probably actively have to try all possible keys to get at one of them, so it would have to be malicious and not just buggy. Regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de

In article <ea80ce02-ecf5-49ee-af3d-96d7c9aec0ec@v13g2000yqc.googlegroups.com>, khan <mushtaqk921@gmail.com> wrote: > Hi, > > In my code am forking child process and doing execv("/bin/sh", argv) > to execute commands. Parent process waits on the child process till > command is executed. > Child process inherits the open file descriptors, open message queues > and sempahores, am not using these in child process and would like to > close them. > Is there a way to find what all message queues, sempahores and files > are opened by parent process? The typical solution is to simply close all open descriptors except stdin, stdout, and stderr. The suggestions on this page may be what you want: http://stackoverflow.com/questions/899038/getting-the-highest-allocated-f ile-descriptor > And is there any other side effect in leaving inherited fd's opened > apart from buggy child process writing to any of the parent fd's ? If the child process never exits (or forks a background process that inherits the fd's and doesn't exit) this could prevent the OS from performing some finalizing actions on a descriptor when the original parent closes it. For instance, if you have a TCP connection open, the FIN won't be sent until all processes that have descriptors referring to the connection close them (unless one of the processs uses shutdown() to send a FIN on demand). -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me ***

Barry Margolin <barmar@alum.mit.edu> writes: > khan <mushtaqk921@gmail.com> wrote: [...] >> And is there any other side effect in leaving inherited fd's opened >> apart from buggy child process writing to any of the parent fd's ? > > If the child process never exits (or forks a background process that > inherits the fd's and doesn't exit) this could prevent the OS from > performing some finalizing actions on a descriptor when the original > parent closes it. For instance, if you have a TCP connection open, the > FIN won't be sent until all processes that have descriptors referring to > the connection close them (unless one of the processs uses shutdown() to > send a FIN on demand). There's also a more serious issue here: Assuming that a listening TCP socket (or something similar) 'leaks through' to an unrelated, long-running process, eg, because that's started from a shell script executed from the program which created the socket and this program than exits for 'some reason', it won't be possible to start it again until the process which unknowingly inherited the socket has also terminated. I've had this once in my own code and a couple of times on various NetASQ firewalls. This is especially funny in a crippled BSD variant like the one used on the latter because there's no tool which directly shows which process is using the socket.

Rainer Weikusat <rweikusat@mssgmbh.com> wrote: > Barry Margolin <barmar@alum.mit.edu> writes: > > khan <mushtaqk921@gmail.com> wrote: > [...] > >> And is there any other side effect in leaving inherited fd's opened > >> apart from buggy child process writing to any of the parent fd's ? > > > > If the child process never exits (or forks a background process that > > inherits the fd's and doesn't exit) this could prevent the OS from > > performing some finalizing actions on a descriptor when the original > > parent closes it. For instance, if you have a TCP connection open, the > > FIN won't be sent until all processes that have descriptors referring to > > the connection close them (unless one of the processs uses shutdown() to > > send a FIN on demand). > There's also a more serious issue here: Assuming that a listening TCP > socket (or something similar) 'leaks through' to an unrelated, > long-running process, eg, because that's started from a shell script > executed from the program which created the socket and this program > than exits for 'some reason', it won't be possible to start it again > until the process which unknowingly inherited the socket has > also terminated. This can also be a problem with device files for devices that can be only opened once - as long as the process that inherited the open device file doesn't exit another attempt to open the device file for the device might either fail or put the pro- gramm trying to open it to sleep (depending on how the device driver handles the situation). Can lead quite a bit of head- scratching;-) That's why every library opening files should set the close-on-exec flag for them immediately, especially when it has no method that would allow the user of the li- brary to obtain the file descriptor. And while the OP wrote that his program willl always wait for the spawned new process to exit it's still an issue since the child process itself could spawn further processes that then also inherit the open files - and the primary child process may not wait for its children to exit... Regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de

> And is there any other side effect in leaving inherited fd's opened > apart from buggy child process writing to any of the parent fd's ? You might end up with a bad security hole, under the circumstances (which are probably unusual with the scenario described): - The parent process is privileged, and leaves some extra fds open. - The child process is supposed to run at lesser privilege, so it drops privileges, then exec's possibly buggy/malicious code in what is supposed to be a sandbox. - The malicious code finds the fds open and does something nasty to them (if, for example, it's the device for the root filesystem it's scribbling on). Writing is probably the worst. Locking for exclusive use might be annoying, depending on what it is that's left open. Reading could be a serious problem, depending on what it is. Leaving extra write ends of a pipe open can result in the read ends never seeing EOF, but just waiting indefinitely. Often, it's the reading process itself that also unknowingly has a write end open, and you just get deadlock.