Deletion of open named pipes

This is a discussion on Deletion of open named pipes within the Linux Programming forums, part of the Platform Specific Boards category; I am creating and opening a named pipe (using mkfifo() ) and the open is blocked (till someone else opens ...

  1. #1
    Registered User
    Join Date
    Nov 2007
    Posts
    2

    Deletion of open named pipes

    I am creating and opening a named pipe (using mkfifo() ) and the open is blocked (till someone else opens in write mode). However, another process is easily able to delete the pipe file while the first process is blocked on it. Is this behaviour ok? Shouldn't the file be locked because someone else is blocked on it?

    Please note that the named pipe was created with permissions 0400. This means only the owner would have the right to modify/delete it, right? The process that deleted it had a different UID and GID. So its not making sense to me how a "rogue" process can just come and delete a file being used by someone else without even having modify permissions on it.

    The only thing I can think of is that the directory permissions are 0777 and that is why he can delete it. Still, the behaviour sounds a little wierd that a busy system file is not locked against deletion.

  2. #2
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by sparkymat View Post
    I am creating and opening a named pipe (using mkfifo() ) and the open is blocked (till someone else opens in write mode). However, another process is easily able to delete the pipe file while the first process is blocked on it. Is this behaviour ok? Shouldn't the file be locked because someone else is blocked on it?
    if you want to "lock" the file, you can put it in a directory with no write permissions, thereby disabling the ability to delete it.

    One of the basic ideas in UNIX is that an open file can be moved or deleted at will. The file/device/FIFO itself will continue to exist, without a name, until it is closed by the last process which has a descriptor on it.

    Coming from a Windows background people are used to thinking that a file which is "in use" is somehow protected from certain kinds of operations. Not true on UNIX.

    Please note that the named pipe was created with permissions 0400. This means only the owner would have the right to modify/delete it, right?
    No. Any user can delete any file, provided they have write permissions on the directory that file is in. It has nothing to do with who owns the file, or the permissions on the file itself.

    So, to prevent deletion of the FIFO, make a directory, put the FIFO in this directory, then remove write permissions on the directory.

  3. #3
    Registered User
    Join Date
    Nov 2007
    Posts
    2
    Quote Originally Posted by brewbuck View Post
    One of the basic ideas in UNIX is that an open file can be moved or deleted at will. The file/device/FIFO itself will continue to exist, without a name, until it is closed by the last process which has a descriptor on it.
    So even if the 2nd process deletes the FIFO file, the opening process can continue using it as long as it has the descriptor?

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by sparkymat View Post
    So even if the 2nd process deletes the FIFO file, the opening process can continue using it as long as it has the descriptor?
    Yes, that's correct - until that process closes the file descriptor.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by sparkymat View Post
    So even if the 2nd process deletes the FIFO file, the opening process can continue using it as long as it has the descriptor?
    Sure -- but in this case, it means your process will hang forever. The call to open() is blocking, waiting for someone to open the write end of the pipe. But because the directory entry has been removed, it is impossible for anybody to open the pipe, because it has no name. The FIFO is still there, but it has become useless because nobody can refer to it. Once you kill the hung process, the last descriptor closes and the FIFO object goes away.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Open Source and Security
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 17
    Last Post: 06-17-2008, 01:23 AM
  2. Open Software License 3.0 Explained
    By laserlight in forum A Brief History of Cprogramming.com
    Replies: 8
    Last Post: 01-08-2008, 07:10 PM
  3. open empty file
    By mystic-d in forum C Programming
    Replies: 2
    Last Post: 11-16-2007, 09:27 AM
  4. To open or not to open ?
    By darfader in forum C Programming
    Replies: 7
    Last Post: 09-24-2003, 08:14 AM
  5. Ghost in the CD Drive
    By Natase in forum A Brief History of Cprogramming.com
    Replies: 17
    Last Post: 10-12-2001, 05:38 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21