From: Ersek, Laszlo on 22 Mar 2010 20:47 In article <ho90v5$u2t$1(a)news.eternal-september.org>, David Given <dg(a)cowlark.com> writes: > The simplest way I can think of is to open a fd to an unlinked temporary > file with some data in it. The child can then call pread() on this, read > the data, and recreate the fake file descriptor from this. (It can't use > read() because if the fd is a socket or a pipe that will consume data.) > But that's rather expensive and is too easy to spoof. (It doesn't have > to be secure, but I do want to avoid false positives.) Put the temporary regular file on a dedicated, "hidden" filesystem. You can later check for fakeness (or rather placeholder-ness for fakeness) by calling fstat() on the fd and verifying the returned st_dev. lacos
From: David Schwartz on 22 Mar 2010 20:53 On Mar 22, 5:11 pm, David Given <d...(a)cowlark.com> wrote: > But now the application opens a file descriptor to the artificial > directory and calls exec(). The file descriptor needs to get propagated, > somehow, to the child (which is also going to be running my library). So > I have to somehow turn my fake file descriptor into a real one, so that > it can be passed across the exec() call and into the child, where my > library will see this file descriptor and get enough information back > out to recreate the fake one. Have the parent create a pipe and pass it to the client. You can pass the file descriptor in an environment variable if you want. The parent is no longer needed, since it's supposed to die after the 'exec', so you can use it to provide information to the client over the pipe. Otherwise, an unlinked file works too. You can pass all the metadata you need and also give it a map to any real file descriptors it inherited and what they mean. DS
From: Ersek, Laszlo on 22 Mar 2010 20:55 In article <ho90v5$u2t$1(a)news.eternal-september.org>, David Given <dg(a)cowlark.com> writes: > I have to somehow turn my fake file descriptor into a real one, so that > it can be passed across the exec() call and into the child, where my > library will see this file descriptor and get enough information back > out to recreate the fake one. Also, putenv() comes to mind. lacos
From: Scott Lurndal on 23 Mar 2010 13:21 David Given <dg(a)cowlark.com> writes: >As part 27 of my 'how can I do this really weird and potentially badly >conceived thing in Unix?' series of questions... > >I've got a wrapper library around file descriptors and file functions. >One of the things this wrapper does is implement a VFS, where the >application using the wrapper library gets a different view of the file >system than is actually there. use something like http://fuse.sourceforge.net/ scott
From: David Given on 23 Mar 2010 15:40 On 23/03/10 00:55, Ersek, Laszlo wrote: > In article <ho90v5$u2t$1(a)news.eternal-september.org>, David Given <dg(a)cowlark.com> writes: > >> I have to somehow turn my fake file descriptor into a real one, so that >> it can be passed across the exec() call and into the child, where my >> library will see this file descriptor and get enough information back >> out to recreate the fake one. > > Also, putenv() comes to mind. Yes, this is definitely the simplest solution. I'm already passing lots of information from the parent to the child via environment variables *anyway*, so it's particularly stupid of me not to think of this... Thank-you all for the suggestions! -- ┌─── dg@cowlark.com ───── http://www.cowlark.com ───── │ │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ } │ --- Conway's Game Of Life, in one line of APL
|
Next
|
Last
Pages: 1 2 Prev: Not printing in thread function Next: How to Remove CVS Directories as a Bash Command? |