rm-ing files with open file descriptors

rm-ing files with open file descriptors

[Doug Alcorn]

I had a weird situation with my application where the user deleted all
the database files while the app was still reading and writing to the
opened file descriptor.  What was weird to me was that the app didn't
complain.  It just went merrily about it's business as if nothing were
wrong.  Of course, after the app shut down all it's data was lost.

Since I didn't expect this behavior I wrote a simple little program to
test it[1].  Sure enough, you can rm a file that has opened file
descriptors and no errors are generated.  Interestingly, sun solaris
does the same thing.  Since this is the case, I thought this might be
a feature instead of a bug (ms-win doesn't allow the rm).  So, my
question is where is this behavior defined?  Is it a kernel issue?
Does POSIX define this behavior?  Is it a libc issue?  

I tried to google this, but couldn't think of the right terms to
describe it.  As I'm not on lkm, I would appreciate a CC: to
<doug@lathi.net>.
-- 
 (__) Doug Alcorn (mailto:doug@lathi.net http://www.lathi.net)
 oo / PGP 02B3 1E26 BCF2 9AAF 93F1  61D7 450C B264 3E63 D543
 |_/  If you're a capitalist and you have the best goods and they're
      free, you don't have to proselytize, you just have to wait. 

Re: rm-ing files with open file descriptors

[Xavier Bestel]

On Fri, 2002-01-18 at 22:11, Doug Alcorn wrote:
> test it[1].  Sure enough, you can rm a file that has opened file
> descriptors and no errors are generated.  Interestingly, sun solaris
> does the same thing.  Since this is the case, I thought this might be
> a feature instead of a bug (ms-win doesn't allow the rm).  So, my
> question is where is this behavior defined?  Is it a kernel issue?

It is defined, and even sometimes used to allocate temporary disk space
(open a file, rm it, you can still r/w your file descriptor and all will
return to free space once your app closes the fd or dies).

	Xav

Re: rm-ing files with open file descriptors

[Ken Brownfield]

This is actually a long-standing UNIXism that is pretty heavily relied-
upon -- for example, opening a temporary file then unlinking it before
use "guarantees" that the file will not stick around in case the app
crashes before it can properly close and unlink.

One nasty side-effect is space allocation -- after unlinking a file and
writing to it, you can fill the disk without the file showing up in 'ls'
or 'du', etc.  Hard to debug.  Stronghold on Solaris used to do this
with log files -- HUP did not discard the old FDs.

-- 
Ken.
brownfld@irridia.com

On Fri, Jan 18, 2002 at 04:11:26PM -0500, Doug Alcorn wrote:
| 
| I had a weird situation with my application where the user deleted all
| the database files while the app was still reading and writing to the
| opened file descriptor.  What was weird to me was that the app didn't
| complain.  It just went merrily about it's business as if nothing were
| wrong.  Of course, after the app shut down all it's data was lost.
| 
| Since I didn't expect this behavior I wrote a simple little program to
| test it[1].  Sure enough, you can rm a file that has opened file
| descriptors and no errors are generated.  Interestingly, sun solaris
| does the same thing.  Since this is the case, I thought this might be
| a feature instead of a bug (ms-win doesn't allow the rm).  So, my
| question is where is this behavior defined?  Is it a kernel issue?
| Does POSIX define this behavior?  Is it a libc issue?  
| 
| I tried to google this, but couldn't think of the right terms to
| describe it.  As I'm not on lkm, I would appreciate a CC: to
| <doug@lathi.net>.
| -- 
|  (__) Doug Alcorn (mailto:doug@lathi.net http://www.lathi.net)
|  oo / PGP 02B3 1E26 BCF2 9AAF 93F1  61D7 450C B264 3E63 D543
|  |_/  If you're a capitalist and you have the best goods and they're
|       free, you don't have to proselytize, you just have to wait. 
| 
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to majordomo@vger.kernel.org
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at  http://www.tux.org/lkml/

Re: rm-ing files with open file descriptors

[Richard B. Johnson]

On 18 Jan 2002, Doug Alcorn wrote:

> 
> I had a weird situation with my application where the user deleted all
> the database files while the app was still reading and writing to the
> opened file descriptor.  What was weird to me was that the app didn't
> complain.  It just went merrily about it's business as if nothing were
> wrong.  Of course, after the app shut down all it's data was lost.
> 
> Since I didn't expect this behavior I wrote a simple little program to
> test it[1].  Sure enough, you can rm a file that has opened file
> descriptors and no errors are generated.  Interestingly, sun solaris
> does the same thing.  Since this is the case, I thought this might be
> a feature instead of a bug (ms-win doesn't allow the rm).  So, my
> question is where is this behavior defined?  Is it a kernel issue?
> Does POSIX define this behavior?  Is it a libc issue?  
> 
> I tried to google this, but couldn't think of the right terms to
> describe it.  As I'm not on lkm, I would appreciate a CC: to
> <doug@lathi.net>.

This is a characteristic of a VFS (Virtual File System) on any
Unix system. The file doesn't go away until it is closed by
everybody that accesses it. However, you can remove or rename it
even when it's open for write by other tasks. If a task has an
open file-descriptor and keeps it open, it could 'fix' a possibly
deleted file, by opening it again with

         new_fd = open("filename", O_CREAT|O_RDWR, 0644);

(without O_TRUNC) and it will remain in existance after all
file descriptors are closed, because it was "created" again
after it was deleted by another task. However, if all descriptors
are closed before you recreate it, data are permanently lost.
In this case, it's a new file.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: rm-ing files with open file descriptors

[J Sloan]

Normal unix behaviour -

It's always been that way....

jjs

Doug Alcorn wrote:

>I had a weird situation with my application where the user deleted all
>the database files while the app was still reading and writing to the
>opened file descriptor.  What was weird to me was that the app didn't
>complain.  It just went merrily about it's business as if nothing were
>wrong.  Of course, after the app shut down all it's data was lost.
>
>Since I didn't expect this behavior I wrote a simple little program to
>test it[1].  Sure enough, you can rm a file that has opened file
>descriptors and no errors are generated.  Interestingly, sun solaris
>does the same thing.  Since this is the case, I thought this might be
>a feature instead of a bug (ms-win doesn't allow the rm).  So, my
>question is where is this behavior defined?  Is it a kernel issue?
>Does POSIX define this behavior?  Is it a libc issue?  
>
>I tried to google this, but couldn't think of the right terms to
>describe it.  As I'm not on lkm, I would appreciate a CC: to
><doug@lathi.net>.
>

Re: rm-ing files with open file descriptors

[Hank Leininger]

On 2002-01-18, Ken Brownfield <brownfld@irridia.com> wrote:

> One nasty side-effect is space allocation -- after unlinking a file and
> writing to it, you can fill the disk without the file showing up in
> 'ls' or 'du', etc.  Hard to debug.  Stronghold on Solaris used to do
> this with log files -- HUP did not discard the old FDs.

Hell, syslogd on Linux used to do that ;)

Linux's /proc/PID/fd/* will (nowadays) tell you the path/name of files that
have been unlinked but have active file descriptors, which at least makes
this less painful to track down *once you think of it*.

--
Hank Leininger <hlein@progressive-comp.com> 
  

Re: rm-ing files with open file descriptors

[Miquel van Smoorenburg]

In article <Pine.LNX.3.95.1020118163838.3008B-100000@chaos.analogic.com>,
Richard B. Johnson <root@chaos.analogic.com> wrote:
>This is a characteristic of a VFS (Virtual File System) on any
>Unix system. The file doesn't go away until it is closed by
>everybody that accesses it. However, you can remove or rename it
>even when it's open for write by other tasks. If a task has an
>open file-descriptor and keeps it open, it could 'fix' a possibly
>deleted file, by opening it again with
>
>         new_fd = open("filename", O_CREAT|O_RDWR, 0644);
>
>(without O_TRUNC) and it will remain in existance after all
>file descriptors are closed, because it was "created" again
>after it was deleted by another task.

Well no. new_fd will refer to a completely new, empty file
which has no relation to the old file at all.

There is no way to recreate a file with a nlink count of 0,
well that is until someone adds flink(fd, newpath) to the kernel.

You're a regular on this list, frankly I'm amazed that you
don't know this ?

Mike.

Re: rm-ing files with open file descriptors

[H. Peter Anvin]

Followup to:  <a2afsg$73g$2@ncc1701.cistron.net>
By author:    Miquel van Smoorenburg <miquels@cistron.nl>
In newsgroup: linux.dev.kernel
> 
> Well no. new_fd will refer to a completely new, empty file
> which has no relation to the old file at all.
> 
> There is no way to recreate a file with a nlink count of 0,
> well that is until someone adds flink(fd, newpath) to the kernel.
> 

This *might* work:

link("/proc/self/fd/40", newpath);

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: rm-ing files with open file descriptors

[Andreas Bombe]

On Fri, Jan 18, 2002 at 04:11:26PM -0500, Doug Alcorn wrote:
> 
> I had a weird situation with my application where the user deleted all
> the database files while the app was still reading and writing to the
> opened file descriptor.  What was weird to me was that the app didn't
> complain.  It just went merrily about it's business as if nothing were
> wrong.  Of course, after the app shut down all it's data was lost.

Others already wrote that this is standard behaviour, but I'm in
lecturing mood right now.

You have to understand that under Unix, the user can not delete files.
Simple as that.  Deleting files happens only at the kernel's discretion
(or in fsck after an unclean reboot).

In Unix style filesystems, files (inodes) and directory entries (links)
are separate things.  Files as in inodes are just an entry in the
filesystem referenced by number.  Directory entries aka file names aka
links are just a name associated with an inode number (try "ls -i"
sometime).

One inode can have multiple links pointing to it, they can be created
with ln (hardlinks, not "ln -s" symlinks).  There is a syscall to deal
with removal of those links, but none that deal with file removal.

If a program does open("xyz") or something, the directory entry "xyz" is
consulted to find the inode, which is then opened.  Now there is a
connection file descriptor <=> inode, the directory entries are totally
out of the loop now.  It doesn't matter whether you move or remove the
links now.

Inodes have a reference count and they are automatically deleted when it
goes to zero.  The reference count is the sum of link count and open
count.  After you remove all links to the opened file it is still
referenced by the open and continues to exist.  Only after the program
having the file open terminates does the ref count go to zero and cause
the file to be really deleted.


Whether that was an intended or accidental feature only someone with
more insight into Unix history can answer.  It's that feature that lets
us do live upgrades of distributions without rebooting (executables and
libraries can be replaced without affecting the currently running
processes), at the very least much easier than it would be without this
behaviour.

It just may not be the most intuitive thing (like file name == file is),
but that is more than made up by its possibilities.

-- 
Andreas Bombe <bombe@informatik.tu-muenchen.de>    DSA key 0x04880A44

Re: rm-ing files with open file descriptors

[Xavier Bestel]

On Sat, 2002-01-19 at 03:29, H. Peter Anvin wrote:
> Followup to:  <a2afsg$73g$2@ncc1701.cistron.net>
> By author:    Miquel van Smoorenburg <miquels@cistron.nl>
> In newsgroup: linux.dev.kernel
> > 
> > Well no. new_fd will refer to a completely new, empty file
> > which has no relation to the old file at all.
> > 
> > There is no way to recreate a file with a nlink count of 0,
> > well that is until someone adds flink(fd, newpath) to the kernel.
> > 
> 
> This *might* work:
> 
> link("/proc/self/fd/40", newpath);
> 

Mmh, in this case /proc/self/fd/40 would be a symlink to nothing ...

	

Re: rm-ing files with open file descriptors

[Miquel van Smoorenburg]

In article <a2almg$vtl$1@cesium.transmeta.com>,
H. Peter Anvin <hpa@zytor.com> wrote:
>Followup to:  <a2afsg$73g$2@ncc1701.cistron.net>
>By author:    Miquel van Smoorenburg <miquels@cistron.nl>
>In newsgroup: linux.dev.kernel
>> 
>> There is no way to recreate a file with a nlink count of 0,
>> well that is until someone adds flink(fd, newpath) to the kernel.
>
>This *might* work:
>
>link("/proc/self/fd/40", newpath);

I used the following perl script to test this, and alas this
doesn't work (yet):

open(FD, ">flink-test.txt") || die;
print FD "flink-test\n";
unlink "flink-test.txt"|| die;
link("/proc/self/fd/" . fileno(FD), "flink-test2.txt") || die;
print "Success.\n";

It results in:

link("/proc/self/fd/3", "flink-test2.txt") = -1 EXDEV (Invalid cross-device link)

This is probably because link() doesn't look up the target of the
symlink, it links the symlink itself. Linux allows symlinks with
a nlink count of 2:

% ln -s a b
% ln b c
ln: `b': warning: making a hard link to a symbolic link is not portable
% ls -l
lrwxrwxrwx    2 miquels  staff           1 Jan 19 11:34 b -> a
lrwxrwxrwx    2 miquels  staff           1 Jan 19 11:34 c -> a

This could be hacked around ofcourse in fs/namei.c, so I tried
it for fun. And indeed, with a minor correction it works:

% perl flink.pl 
Success.

I now have a flink-test2.txt file. That is pretty cool ;)

Here's the patch:

--- linux-2.4.15-pre4/fs/namei.c.orig	Wed Oct 17 23:46:29 2001
+++ linux-2.4.15-pre4/fs/namei.c	Sat Jan 19 12:08:13 2002
@@ -22,6 +22,7 @@
 #include <linux/dnotify.h>
 #include <linux/smp_lock.h>
 #include <linux/personality.h>
+#include <linux/proc_fs.h>
 
 #include <asm/namei.h>
 #include <asm/uaccess.h>
@@ -1640,6 +1641,16 @@
 			error = path_walk(from, &old_nd);
 		if (error)
 			goto exit;
+#if 1 /* flink()-like support */
+		if (old_nd.mnt->mnt_sb->s_magic == PROC_SUPER_MAGIC) {
+			path_release(&old_nd);
+			if (path_init(from, LOOKUP_POSITIVE|LOOKUP_FOLLOW,
+			    &old_nd))
+				error = path_walk(from, &old_nd);
+			if (error)
+				goto exit;
+		}
+#endif
 		if (path_init(to, LOOKUP_PARENT, &nd))
 			error = path_walk(to, &nd);
 		if (error)



Mike.

Re: rm-ing files with open file descriptors

[Ville Herva]

On Fri, Jan 18, 2002 at 06:29:36PM -0800, you [H. Peter Anvin] said:
> 
> This *might* work:
> 
> link("/proc/self/fd/40", newpath);

I don't think so: firstly, it would create a cross device link and secondly,
/proc/<pid>/fd/* are symbolic links. See:

/tmp>while true; do sleep 1; echo kukkanen; done > r &
[1] 19925
/tmp>L /proc/19925/fd 
total 0
lrwx------    1 root     root           64 Jan 19 13:10 0 -> /dev/pts/7
l-wx------    1 root     root           64 Jan 19 13:10 1 -> /tmp/r
lrwx------    1 root     root           64 Jan 19 13:10 2 -> /dev/pts/7
/tmp>rm r               
/tmp>L /proc/19925/fd
total 0
lrwx------    1 root     root           64 Jan 19 13:10 0 -> /dev/pts/7
l-wx------    1 root     root           64 Jan 19 13:10 1 -> /tmp/r (deleted)
lrwx------    1 root     root           64 Jan 19 13:10 2 -> /dev/pts/7
/tmp>ln /proc/19925/fd/1 r2
ln: /proc/19925/fd/1: warning: making a hard link to a symbolic link is not portable
ln: create hard link `r2' to `/proc/19925/fd/1': Invalid cross-device link

I think one has to use lsof, ps and/or fuser and then kill.


-- v --

v@iki.fi

Re: rm-ing files with open file descriptors

[Alexander Viro]

On Sat, 19 Jan 2002, Miquel van Smoorenburg wrote:
 
> This could be hacked around ofcourse in fs/namei.c, so I tried
> it for fun. And indeed, with a minor correction it works:
> 
> % perl flink.pl 
> Success.
> 
> I now have a flink-test2.txt file. That is pretty cool ;)

It's also a security hole.

Re: rm-ing files with open file descriptors

[Miquel van Smoorenburg]

In article <Pine.GSO.4.21.0201190627310.3523-100000@weyl.math.psu.edu>,
Alexander Viro  <viro@math.psu.edu> wrote:
>On Sat, 19 Jan 2002, Miquel van Smoorenburg wrote:
> 
>> This could be hacked around ofcourse in fs/namei.c, so I tried
>> it for fun. And indeed, with a minor correction it works:
>> 
>> % perl flink.pl 
>> Success.
>> 
>> I now have a flink-test2.txt file. That is pretty cool ;)
>
>It's also a security hole.

How is linking back a file into the normal namespace anymore
a security hole as having it under /proc or keeping an fd to it open?

I've searched google on the subject but couldn't find anything relevant.
Yes this has been proposed a few times for both BSD and Linux, often
in combination with "unattached open" (O_NULL or somesuch) that opens
a file with a nlink count of 0. It's supposed to be a perfect way to
create a new file and link it atomically into place without creating
(named) tempfiles.

Mike.

Re: rm-ing files with open file descriptors

[Matthias Schniedermeyer]

> > Well no. new_fd will refer to a completely new, empty file
> > which has no relation to the old file at all.
> > 
> > There is no way to recreate a file with a nlink count of 0,
> > well that is until someone adds flink(fd, newpath) to the kernel.
> > 
> 
> This *might* work:
> 
> link("/proc/self/fd/40", newpath);

cat /proc/<id>/fd/<nr> > whatever
actually works.

"Even Better(tm)" would be if
ln /proc/<id>/fd/<nr> whatever
or
ln <Inode> whatever (lsof delivers the needed Inode-nr)
would work.

Otherwise you have a problem to recover files when you have insufficent
disc space. Imagine a file that is 1GB in size and you have 512MB left
on the hdd. Currently i don't see a chance to recover such a file
without problems.





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

Re: rm-ing files with open file descriptors

[Xavier Bestel]

On Sat, 2002-01-19 at 13:16, Matthias Schniedermeyer wrote:
> > > Well no. new_fd will refer to a completely new, empty file
> > > which has no relation to the old file at all.
> > > 
> > > There is no way to recreate a file with a nlink count of 0,
> > > well that is until someone adds flink(fd, newpath) to the kernel.
> > > 
> > 
> > This *might* work:
> > 
> > link("/proc/self/fd/40", newpath);
> 
> cat /proc/<id>/fd/<nr> > whatever
> actually works.

Once it's unliked ? I doubt it.

Re: rm-ing files with open file descriptors

[Alexander Viro]

On 19 Jan 2002, Xavier Bestel wrote:

> On Sat, 2002-01-19 at 13:16, Matthias Schniedermeyer wrote:
> > > > Well no. new_fd will refer to a completely new, empty file
> > > > which has no relation to the old file at all.
> > > > 
> > > > There is no way to recreate a file with a nlink count of 0,
> > > > well that is until someone adds flink(fd, newpath) to the kernel.
> > > > 
> > > 
> > > This *might* work:
> > > 
> > > link("/proc/self/fd/40", newpath);
> > 
> > cat /proc/<id>/fd/<nr> > whatever
> > actually works.
> 
> Once it's unliked ? I doubt it.

Egads...  It certainly works, unlinked or not.  Please learn the basics of
Unix filesystem semantics.

Re: rm-ing files with open file descriptors

[Xavier Bestel]

On Sat, 2002-01-19 at 13:29, Alexander Viro wrote:
> 
> 
> On 19 Jan 2002, Xavier Bestel wrote:
> 
> > On Sat, 2002-01-19 at 13:16, Matthias Schniedermeyer wrote:
> > > > > Well no. new_fd will refer to a completely new, empty file
> > > > > which has no relation to the old file at all.
> > > > > 
> > > > > There is no way to recreate a file with a nlink count of 0,
> > > > > well that is until someone adds flink(fd, newpath) to the kernel.
> > > > > 
> > > > 
> > > > This *might* work:
> > > > 
> > > > link("/proc/self/fd/40", newpath);
> > > 
> > > cat /proc/<id>/fd/<nr> > whatever
> > > actually works.
> > 
> > Once it's unliked ? I doubt it.
> 
> Egads...  It certainly works, unlinked or not.  Please learn the basics of
> Unix filesystem semantics.

Indeed, it works, but it doesn't with a true symlink. What kind of a
link is that /proc/<id>/fd/<nr> entry ? It's not a symlink even if it
looks like one.

Re: rm-ing files with open file descriptors

[Rogier Wolff]

Xavier Bestel wrote:
> On Sat, 2002-01-19 at 13:29, Alexander Viro wrote:
> > 
> > 
> > On 19 Jan 2002, Xavier Bestel wrote:
> > 
> > > On Sat, 2002-01-19 at 13:16, Matthias Schniedermeyer wrote:
> > > > > > Well no. new_fd will refer to a completely new, empty file
> > > > > > which has no relation to the old file at all.
> > > > > > 
> > > > > > There is no way to recreate a file with a nlink count of 0,
> > > > > > well that is until someone adds flink(fd, newpath) to the kernel.
> > > > > > 
> > > > > 
> > > > > This *might* work:
> > > > > 
> > > > > link("/proc/self/fd/40", newpath);
> > > > 
> > > > cat /proc/<id>/fd/<nr> > whatever
> > > > actually works.
> > > 
> > > Once it's unliked ? I doubt it.
> > 
> > Egads...  It certainly works, unlinked or not.  Please learn the basics of
> > Unix filesystem semantics.
> 
> Indeed, it works, but it doesn't with a true symlink. What kind of a
> link is that /proc/<id>/fd/<nr> entry ? It's not a symlink even if it
> looks like one.

Highly correct!

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: rm-ing files with open file descriptors

[Horst von Brand]

Miquel van Smoorenburg <miquels@cistron.nl> said:

[...]

> There is no way to recreate a file with a nlink count of 0,
> well that is until someone adds flink(fd, newpath) to the kernel.

It stays around under /proc/<pid>/fd/<xxx>, so you could grab it there. It
is _announced_ as a symlink to the deleted file, but you get its contents
anyway. [2.4.18pre4]
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: rm-ing files with open file descriptors

[christophe barbé]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

On Sat, Jan 19, 2002 at 05:18:57AM +0100, Andreas Bombe wrote:
> Whether that was an intended or accidental feature only someone with
> more insight into Unix history can answer.  It's that feature that lets
> us do live upgrades of distributions without rebooting (executables and
> libraries can be replaced without affecting the currently running
> processes), at the very least much easier than it would be without this
> behaviour.

I remember that previous debian release come with a patched kernel to
allow live upgrade. It was explained in the FAQ that the patch was
required for this purpose.

   7.2 Debian claims to be able to update a running program;
      how is this accomplished?

The debian FAQ has been updated because now debian uses a pristine
kernel.

What was in this patch?

Christophe

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Cats are rather delicate creatures and they are subject to a good
many ailments, but I never heard of one who suffered from insomnia.
--Joseph Wood Krutch

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: rm-ing files with open file descriptors

[Horst von Brand]

Miquel van Smoorenburg <miquels@cistron.nl> said:

[...]

> It results in:
> 
> link("/proc/self/fd/3", "flink-test2.txt") = -1 EXDEV (Invalid cross-device lin
> k)
> 
> This is probably because link() doesn't look up the target of the
> symlink, it links the symlink itself. Linux allows symlinks with
> a nlink count of 2:
> 
> % ln -s a b
> % ln b c
> ln: `b': warning: making a hard link to a symbolic link is not portable
> % ls -l
> lrwxrwxrwx    2 miquels  staff           1 Jan 19 11:34 b -> a
> lrwxrwxrwx    2 miquels  staff           1 Jan 19 11:34 c -> a
> 
> This could be hacked around ofcourse in fs/namei.c, so I tried
> it for fun. And indeed, with a minor correction it works:
> 
> % perl flink.pl 
> Success.
> 
> I now have a flink-test2.txt file. That is pretty cool ;)

This is a possible security risk: The unlinking program thinks the file is
forever inaccessible, but it isn't...
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: rm-ing files with open file descriptors

[Horst von Brand]

Alexander Viro <viro@math.psu.edu> said:
> On 19 Jan 2002, Xavier Bestel wrote:
> > On Sat, 2002-01-19 at 13:16, Matthias Schniedermeyer wrote:

[...]

> > > cat /proc/<id>/fd/<nr> > whatever
> > > actually works.
> > 
> > Once it's unliked ? I doubt it.
> 
> Egads...  It certainly works, unlinked or not.  Please learn the basics of
> Unix filesystem semantics.

It does show up as a broken symlink for ls(1)...
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: rm-ing files with open file descriptors

[Mr. James W. Laferriere]

On Sat, 19 Jan 2002, Horst von Brand wrote:
> Miquel van Smoorenburg <miquels@cistron.nl> said:
> [...]
> > It results in:
> > link("/proc/self/fd/3", "flink-test2.txt") = -1 EXDEV (Invalid cross-device link)
> > This is probably because link() doesn't look up the target of the
> > symlink, it links the symlink itself. Linux allows symlinks with
> > a nlink count of 2:
> > % ln -s a b
> > % ln b c
> > ln: `b': warning: making a hard link to a symbolic link is not portable
> > % ls -l
> > lrwxrwxrwx    2 miquels  staff           1 Jan 19 11:34 b -> a
> > lrwxrwxrwx    2 miquels  staff           1 Jan 19 11:34 c -> a
> > This could be hacked around ofcourse in fs/namei.c, so I tried
> > it for fun. And indeed, with a minor correction it works:
> > % perl flink.pl
> > Success.
> > I now have a flink-test2.txt file. That is pretty cool ;)

> This is a possible security risk: The unlinking program thinks the file is
> forever inaccessible, but it isn't...
	Will the ability to access this linked file still be there  across
	a reboot ?  Or an fsck ?  Tia ,  JimL

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: rm-ing files with open file descriptors

[Kai Henningsen]

viro@math.psu.edu (Alexander Viro)  wrote on 19.01.02 in <Pine.GSO.4.21.0201190627310.3523-100000@weyl.math.psu.edu>:

> On Sat, 19 Jan 2002, Miquel van Smoorenburg wrote:
>
> > This could be hacked around ofcourse in fs/namei.c, so I tried
> > it for fun. And indeed, with a minor correction it works:
> >
> > % perl flink.pl
> > Success.
> >
> > I now have a flink-test2.txt file. That is pretty cool ;)
>
> It's also a security hole.

It may well be one when going via /proc. But is it one when going via a  
(hypothetical) proper flink(2)? If so, why?

Note that every process who has a filehandle open for reading can already  
get at the file contents and write them to a completely new file, and  
every process who has it open for writing can already change its contents  
to everything it likes. So I can see read|write checks on the file handle.  
Also all the usual link(2) checks. What else could be a hole?

MfG Kai

Re: rm-ing files with open file descriptors

[Miquel van Smoorenburg]

According to Horst von Brand:
> > I now have a flink-test2.txt file. That is pretty cool ;)
> 
> This is a possible security risk: The unlinking program thinks the file is
> forever inaccessible, but it isn't...

Why. If you keep an fd open to it it's accessible anyway, and if
you like you can copy it to a new file. Or you could link(2) it
beforehand, etc etc

Mike.

Re: rm-ing files with open file descriptors

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1284 bytes --]

christophe.barbe.ml@online.fr (christophe barbé)  wrote on 19.01.02 in <20020119145132.GA972@online.fr>:

> On Sat, Jan 19, 2002 at 05:18:57AM +0100, Andreas Bombe wrote:
> > Whether that was an intended or accidental feature only someone with
> > more insight into Unix history can answer.  It's that feature that lets
> > us do live upgrades of distributions without rebooting (executables and
> > libraries can be replaced without affecting the currently running
> > processes), at the very least much easier than it would be without this
> > behaviour.
>
> I remember that previous debian release come with a patched kernel to
> allow live upgrade. It was explained in the FAQ that the patch was
> required for this purpose.

Complete and utter bullshit. This was never true, and the FAQ never  
claimed this.

>    7.2 Debian claims to be able to update a running program;
>       how is this accomplished?

... under which was originally explained how running demons would be  
restarted, and later it was also mentioned that replacing in-use files is  
possible under Unix. Nothing more. (Google groups will happily find those  
versions, they were in use from 1996 to 2001 according to the archive.)

> What was in this patch?

The patch only exists in your fantasy.

MfG Kai

Re: rm-ing files with open file descriptors

[Rob Landley]

On Friday 18 January 2002 04:28 pm, Ken Brownfield wrote:
> This is actually a long-standing UNIXism that is pretty heavily relied-
> upon -- for example, opening a temporary file then unlinking it before
> use "guarantees" that the file will not stick around in case the app
> crashes before it can properly close and unlink.

It's fun with named pipes, too.  Allows you to use the child's PID as the 
temp file name really easily...

Rob

Re: rm-ing files with open file descriptors

[Rob Landley]

On Saturday 19 January 2002 10:21 am, Horst von Brand wrote:
> Miquel van Smoorenburg <miquels@cistron.nl> said:
>
> [...]
>
> > It results in:
> >
> > link("/proc/self/fd/3", "flink-test2.txt") = -1 EXDEV (Invalid
> > cross-device lin k)
> >
> > This is probably because link() doesn't look up the target of the
> > symlink, it links the symlink itself. Linux allows symlinks with
> > a nlink count of 2:
> >
> > % ln -s a b
> > % ln b c
> > ln: `b': warning: making a hard link to a symbolic link is not portable
> > % ls -l
> > lrwxrwxrwx    2 miquels  staff           1 Jan 19 11:34 b -> a
> > lrwxrwxrwx    2 miquels  staff           1 Jan 19 11:34 c -> a
> >
> > This could be hacked around ofcourse in fs/namei.c, so I tried
> > it for fun. And indeed, with a minor correction it works:
> >
> > % perl flink.pl
> > Success.
> >
> > I now have a flink-test2.txt file. That is pretty cool ;)
>
> This is a possible security risk: The unlinking program thinks the file is
> forever inaccessible, but it isn't...

It's only accessable to the same user.  (permissions 700 in /proc/blah/fs.)  
If you're running at the same user, you can attach a debugger to the process 
and look at anything it's got.  So it's just an easier way to do something 
you could effectively already do anyway...

Rob

Re: rm-ing files with open file descriptors

[Rob Landley]

On Saturday 19 January 2002 10:32 am, Mr. James W. Laferriere wrote:

> > This is a possible security risk: The unlinking program thinks the file
> > is forever inaccessible, but it isn't...
>
> 	Will the ability to access this linked file still be there  across
> 	a reboot ?  Or an fsck ?  Tia ,  JimL

Actually deleting files with a link count of zero is one of the things fsck 
is for, I believe...

Rob

Re: rm-ing files with open file descriptors

[christophe barbé]

[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]

On Sat, Jan 19, 2002 at 08:01:00PM +0200, Kai Henningsen wrote:
> christophe.barbe.ml@online.fr (christophe barb?)  wrote on 19.01.02 in <20020119145132.GA972@online.fr>:
> 
> > On Sat, Jan 19, 2002 at 05:18:57AM +0100, Andreas Bombe wrote:
> > > Whether that was an intended or accidental feature only someone with
> > > more insight into Unix history can answer.  It's that feature that lets
> > > us do live upgrades of distributions without rebooting (executables and
> > > libraries can be replaced without affecting the currently running
> > > processes), at the very least much easier than it would be without this
> > > behaviour.
> >
> > I remember that previous debian release come with a patched kernel to
> > allow live upgrade. It was explained in the FAQ that the patch was
> > required for this purpose.
> 
> Complete and utter bullshit. This was never true, and the FAQ never  
> claimed this.
> 
> >    7.2 Debian claims to be able to update a running program;
> >       how is this accomplished?
> 
> ... under which was originally explained how running demons would be  
> restarted, and later it was also mentioned that replacing in-use files is  
> possible under Unix. Nothing more. (Google groups will happily find those  
> versions, they were in use from 1996 to 2001 according to the archive.)
> 
> > What was in this patch?
> 
> The patch only exists in your fantasy.

Ok you are right. I've checked old versions of this FAQ and this patch
only exists in my fantasy.

I take your 'Complete and utter bullshit' comment as a debian compliment
and not as an insult.

Christophe

> 
> MfG Kai
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Ce que l'on conçoit bien s'énonce clairement,
Et les mots pour le dire arrivent aisément.
   Nicolas Boileau, L'Art poétique

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: rm-ing files with open file descriptors

[Chris Wedgwood]

On Sat, Jan 19, 2002 at 06:28:36AM -0500, Alexander Viro wrote:

    It's also a security hole.

As such would an flink impementation also be considered a bad thing?




  --cw

Re: rm-ing files with open file descriptors

[Remi Turk]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On Sat, Jan 19, 2002 at 12:50:24AM +0000, Miquel van Smoorenburg wrote:
> There is no way to recreate a file with a nlink count of 0,
> well that is until someone adds flink(fd, newpath) to the kernel.
Which I actually posted a patch for in 2.4.0-test1 time :)

% ll -i old
32619 -rw-r--r--   1 remi     users          14 Jul 31 15:44 old
% exec 5<old
% rm old
% ~/src/flink/flink 5 new
% ll -i new
32619 -rw-r--r--   1 remi     users          14 Jul 31 15:44 new

The more interesting part - open(O_ANONYMOUS) or something like
that looked much harder to do. (IOW, I gave up ;) )

Happy hacking

	Remi

-- 
See the light and feel my warm desire,
Run through your veins like the evening sun
It will live but no eyes will see it,
I'll bless your name before I die.

Key fingerprint = CC90 A1BA CF6D 891C 5B88  C543 6C5F C469 8F20 70F4

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: rm-ing files with open file descriptors

[Richard Kettlewell]

kaih@khms.westfalen.de (Kai Henningsen) writes:
> viro@math.psu.edu (Alexander Viro) wrote:
>> On Sat, 19 Jan 2002, Miquel van Smoorenburg wrote:

>>> I now have a flink-test2.txt file. That is pretty cool ;)
>> 
>> It's also a security hole.
> 
> It may well be one when going via /proc. But is it one when going
> via a (hypothetical) proper flink(2)? If so, why?
> 
> Note that every process who has a filehandle open for reading can
> already get at the file contents and write them to a completely new
> file, and every process who has it open for writing can already
> change its contents to everything it likes. So I can see read|write
> checks on the file handle.  Also all the usual link(2) checks. What
> else could be a hole?

If the file descriptor you have was opened O_RDONLY, but you have
write permission on the file itself, then creating a new name for it
would allow you to open it O_RDWR.

I'm not 100% convinced by this argument.  If you really want a
particular user not to be able to write to a file, the certain answer
is to set its permissions appropriately, rather than rely on it having
no name.

One could make the hypothetical flink(2) only work on O_RDWR file
descriptors, or only on files owned by the euid of the calling
process.

-- 
http://www.greenend.org.uk/rjk/

Re: rm-ing files with open file descriptors

[Horst von Brand]

Miquel van Smoorenburg <miquels@cistron.nl> said:
> According to Horst von Brand:
> > > I now have a flink-test2.txt file. That is pretty cool ;)
> > 
> > This is a possible security risk: The unlinking program thinks the file is
> > forever inaccessible, but it isn't...
> 
> Why. If you keep an fd open to it it's accessible anyway, and if
> you like you can copy it to a new file. Or you could link(2) it
> beforehand, etc etc

Right. So the "staying around in /proc" is a risk.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: rm-ing files with open file descriptors

[Doug McNaught]

Richard Kettlewell <rjk@terraraq.org.uk> writes:

> If the file descriptor you have was opened O_RDONLY, but you have
> write permission on the file itself, then creating a new name for it
> would allow you to open it O_RDWR.

Are you sure about this?  Permissions are stored in the inode, not the
directory entry. 

-Doug
-- 
Let us cross over the river, and rest under the shade of the trees.
   --T. J. Jackson, 1863

Re: rm-ing files with open file descriptors

[Ville Herva]

On Sun, Jan 20, 2002 at 03:23:59PM +0100, you [Remi Turk] claimed:
>
> Which I actually posted a patch for in 2.4.0-test1 time :)
> 
> % ll -i old
> 32619 -rw-r--r--   1 remi     users          14 Jul 31 15:44 old
> % exec 5<old
> % rm old
> % ~/src/flink/flink 5 new
> % ll -i new
> 32619 -rw-r--r--   1 remi     users          14 Jul 31 15:44 new
> 
> The more interesting part - open(O_ANONYMOUS) or something like
> that looked much harder to do. (IOW, I gave up ;) )

Just out of interest (I'm not actually suggesting this would be useful, or
feasible): what about ilink(dev, inode_nr, "path") or iopen(dev, inode_nr)?

Or /proc/inodes/dev/<nr> ?



-- v --

v@iki.fi

Re: rm-ing files with open file descriptors

[Andreas Ferber]

On Sun, Jan 20, 2002 at 10:02:55PM +0200, Ville Herva wrote:
> 
> Just out of interest (I'm not actually suggesting this would be useful, or
> feasible): what about ilink(dev, inode_nr, "path") or iopen(dev, inode_nr)?
> 
> Or /proc/inodes/dev/<nr> ?

...which would successfully defeat any access control scheme based on
directory permissions...

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: rm-ing files with open file descriptors

[Ville Herva]

On Sun, Jan 20, 2002 at 09:44:31PM +0100, you [Andreas Ferber] claimed:
> On Sun, Jan 20, 2002 at 10:02:55PM +0200, Ville Herva wrote:
> > 
> > Just out of interest (I'm not actually suggesting this would be useful, or
> > feasible): what about ilink(dev, inode_nr, "path") or iopen(dev, inode_nr)?
> > 
> > Or /proc/inodes/dev/<nr> ?
> 
> ...which would successfully defeat any access control scheme based on
> directory permissions...

Yeah - it could be root-only.

But it's propably not useful anyway.


-- v --

v@iki.fi

Re: rm-ing files with open file descriptors

[Miquel van Smoorenburg]

In article <843d119h0g.fsf@rjk.greenend.org.uk>,
Richard Kettlewell  <rjk@terraraq.org.uk> wrote:
>If the file descriptor you have was opened O_RDONLY, but you have
>write permission on the file itself, then creating a new name for it
>would allow you to open it O_RDWR.

/proc allows for this anyway.

open("knuth.txt", O_RDONLY)             = 3
unlink("knuth.txt")                     = 0
open("/proc/self/fd/3", O_RDWR)         = 4

Mike.

Re: rm-ing files with open file descriptors

[Horst von Brand]

Ville Herva <vherva@niksula.hut.fi> said:
> On Sun, Jan 20, 2002 at 09:44:31PM +0100, you [Andreas Ferber] claimed:
> > On Sun, Jan 20, 2002 at 10:02:55PM +0200, Ville Herva wrote:
> > > 
> > > Just out of interest (I'm not actually suggesting this would be useful, or
> > > feasible): what about ilink(dev, inode_nr, "path") or iopen(dev, inode_nr)?
> > > 
> > > Or /proc/inodes/dev/<nr> ?
> > 
> > ...which would successfully defeat any access control scheme based on
> > directory permissions...
> 
> Yeah - it could be root-only.
> 
> But it's propably not useful anyway.

There are filesystems around (MSDOS, VFAT) that haven't got fixed inode
numbers for files. There are networked filesystems where this would need
radical changes to the server side. Some even make up inode numbers on the
fly IIRC.

If in dire need, you could hack something together for <favorite
filesystem> by groveling over the disk image. e2fsprogs' libraries should
come handy...
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: rm-ing files with open file descriptors

[Ville Herva]

On Mon, Jan 21, 2002 at 10:06:57AM +0100, you [Horst von Brand] claimed:
> 
> There are filesystems around (MSDOS, VFAT) that haven't got fixed inode
> numbers for files. There are networked filesystems where this would need
> radical changes to the server side. Some even make up inode numbers on the
> fly IIRC.

True.
 
> If in dire need, you could hack something together for <favorite
> filesystem> by groveling over the disk image. e2fsprogs' libraries should
> come handy...

Well, I'll have to come up with the dire need first - or any need indeed :).
Just playing around with the idea.

IIRC, Stephen Tweedie had made such a patch for ext2.


-- v --

v@iki.fi

Re: rm-ing files with open file descriptors

[Pavel Machek]

Hi!

> >> This could be hacked around ofcourse in fs/namei.c, so I tried
> >> it for fun. And indeed, with a minor correction it works:
> >> 
> >> % perl flink.pl 
> >> Success.
> >> 
> >> I now have a flink-test2.txt file. That is pretty cool ;)
> >
> >It's also a security hole.
> 
> How is linking back a file into the normal namespace anymore
> a security hole as having it under /proc or keeping an fd to it
> open?

Imagine you want to delete my file, you are root.

Before, you could rm it, then kill all my processes.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: rm-ing files with open file descriptors

[Herbert Xu]

Pavel Machek <pavel@suse.cz> wrote:

>> How is linking back a file into the normal namespace anymore
>> a security hole as having it under /proc or keeping an fd to it
>> open?

> Imagine you want to delete my file, you are root.

> Before, you could rm it, then kill all my processes.

No you can't.  Your processes may be in a tight loop making new links
for the file.  The only safe solution is to kill the processes first,
then delete the file.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt