fork - should not inherit file descriptor - Unix

This is a discussion on fork - should not inherit file descriptor - Unix ; I want to execute a critical piece of code [not executable/binary] with a set of file descriptor that is not shared with the calling/ parent process, Any ideas i dont want to use system/execs? details --- thread-1: close fd which ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: fork - should not inherit file descriptor

  1. fork - should not inherit file descriptor

    I want to execute a critical piece of code [not executable/binary]
    with a set of file descriptor that is not shared with the calling/
    parent process, Any ideas i dont want to use system/execs?

    details ---

    thread-1:
    close fd which has a value of 4.

    thread-2:
    stuck on select -with time out of 2 sec & next line is read on fd
    while thread one does a close on fd/4

    thread-3:
    I do a fork
    and in the child i open a fd .
    and starts writing kernel in kernel partition.

    1 in 100 times i get fd = thread-1 fd that i.e., i get fd as 4 here.
    now thread-2 select trips/comesout and executes read on fd

    boom, the fd pointer is screwed now and the kernel partition is
    corrupt.

    Thanks for your help.
    vj

  2. Re: fork - should not inherit file descriptor

    vj wrote:
    > I want to execute a critical piece of code [not executable/binary]
    > with a set of file descriptor that is not shared with the calling/
    > parent process, Any ideas i dont want to use system/execs?


    You're a bit short on...

    > details ---


    > thread-1:
    > close fd which has a value of 4.


    > thread-2:
    > stuck on select -with time out of 2 sec & next line is read on fd
    > while thread one does a close on fd/4


    If the file you try to read on has already been closed by thread-1
    then I guess read() will return -1 and set errno to EBADF.

    > thread-3:
    > I do a fork
    > and in the child i open a fd .


    This is a new fd, not related to any files you opened in the parent.

    > and starts writing kernel in kernel partition.


    > 1 in 100 times i get fd = thread-1 fd that i.e., i get fd as 4 here.
    > now thread-2 select trips/comesout and executes read on fd


    Can you rephrase this? Does that mean that in 1 out of 100 cases
    you get a fd with a value of 4 in the child? If this is the case
    then obviously thread-1 already had closed the fd with number 4
    before the fork() was executed in thread-3 and if you now open a
    new file in the child it gets the lowest numbered available fd
    number. But that filel has no relationship to what was closed
    before and can't influence wht happens in thread-2. The child is
    running as a new, independent process and only the file descrip-
    tors it inherited from the parent are shared with the parent.
    So thread-2 can't do anything about that newly opened file.

    > boom, the fd pointer is screwed now and the kernel partition is
    > corrupt.


    Which file pointer? And what should be screwing it?

    Regards, Jens
    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

  3. Re: fork - should not inherit file descriptor

    >I want to execute a critical piece of code [not executable/binary]
    >with a set of file descriptor that is not shared with the calling/
    >parent process, Any ideas i dont want to use system/execs?


    Immediately after the fork(), in the child, call close() on any
    file descriptors you don't want shared.

    Is there a reason that won't work?



  4. Re: fork - should not inherit file descriptor

    On Jun 3, 4:36 pm, vj wrote:
    > I want to execute a critical piece of code [not executable/binary]
    > with a set of file descriptor that is not shared with the calling/
    > parent process, Any ideas i dont want to use system/execs?
    >
    > details ---




    I'm not sure that I understand what you mean, but are you aware that
    when you call fork(), you create a duplicate of all the threads of the
    process, not just the thread that called fork()?

    Not sure if that might help...
    viza

  5. Re: fork - should not inherit file descriptor

    On Jun 3, 6:10 pm, viza wrote:
    ....
    > I'm not sure that I understand what you mean, but are you aware
    > that when you call fork(), you create a duplicate of all the threads
    > of the process, not just the thread that called fork()?


    That not true on systems that follow the Single Unix Standard. From
    the page describing fork():
    http://www.opengroup.org/onlinepubs/...ions/fork.html
    ....
    A process shall be created with a single thread. If a multi-
    threaded process calls fork(), the new process shall contain
    a replica of the calling thread and its entire address space,
    possibly including the states of mutexes and other resources.

    ....and then the rationale section of that page includes a long section
    describing why that model ("fork1") was choosen over the "forkall"
    model.

    Note that there are systems where the behavior of fork() depends on
    how you compile and/or link the program. The notable example is
    Solaris up to version 9, where fork() implemented the "fork1"
    semantics only if you link with libpthread; programs that linked
    against libthread but not libpthread would have the "forkall"
    semantics.


    Philip Guenther

  6. Re: fork - should not inherit file descriptor

    On Jun 3, 8:36*am, vj wrote:

    > thread-1:
    > close fd which has a value of 4.


    > thread-2:
    > stuck on select -with time out of 2 sec & next line is read on fd
    > while thread one does a close on fd/4


    You cannot allow one thread to release a resource while another thread
    is or might be using it. If thread 1 is going to close fd 4, it must
    ensure that no other thread is currently using that file descriptor or
    is about to use it.

    DS

  7. Re: fork - should not inherit file descriptor

    viza writes:

    >On Jun 3, 4:36 pm, vj wrote:
    >> I want to execute a critical piece of code [not executable/binary]
    >> with a set of file descriptor that is not shared with the calling/
    >> parent process, Any ideas i dont want to use system/execs?
    >>
    >> details ---


    >


    >I'm not sure that I understand what you mean, but are you aware that
    >when you call fork(), you create a duplicate of all the threads of the
    >process, not just the thread that called fork()?


    POSIX says that "fork()" creates a new process with ONLY the calling
    thread (only one thread after fork()).

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

+ Reply to Thread