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
<[email protected]>.
--
(__) Doug Alcorn (mailto:[email protected] 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.
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
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.
[email protected]
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
| <[email protected]>.
| --
| (__) Doug Alcorn (mailto:[email protected] 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 [email protected]
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
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
> <[email protected]>.
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.
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
><[email protected]>.
>
On 2002-01-18, Ken Brownfield <[email protected]> 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 <[email protected]>
In article <[email protected]>,
Richard B. Johnson <[email protected]> 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.
Followup to: <[email protected]>
By author: Miquel van Smoorenburg <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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 <[email protected]> DSA key 0x04880A44
On Sat, 2002-01-19 at 03:29, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Miquel van Smoorenburg <[email protected]>
> 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 ...
In article <[email protected]>,
H. Peter Anvin <[email protected]> wrote:
>Followup to: <[email protected]>
>By author: Miquel van Smoorenburg <[email protected]>
>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.
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 --
[email protected]
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.
In article <[email protected]>,
Alexander Viro <[email protected]> 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.
> > 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.
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.
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.
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.
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.
--
** [email protected] ** 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.
Miquel van Smoorenburg <[email protected]> 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
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? <[email protected]>
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
Miquel van Smoorenburg <[email protected]> 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
Alexander Viro <[email protected]> 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
On Sat, 19 Jan 2002, Horst von Brand wrote:
> Miquel van Smoorenburg <[email protected]> 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 |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
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.
[email protected] (christophe barb?) wrote on 19.01.02 in <[email protected]>:
> 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
[email protected] (Alexander Viro) wrote on 19.01.02 in <[email protected]>:
> 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
On Sat, Jan 19, 2002 at 08:01:00PM +0200, Kai Henningsen wrote:
> [email protected] (christophe barb?) wrote on 19.01.02 in <[email protected]>:
>
> > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Christophe Barb? <[email protected]>
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
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
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
On Saturday 19 January 2002 10:21 am, Horst von Brand wrote:
> Miquel van Smoorenburg <[email protected]> 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
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
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
[email protected] (Kai Henningsen) writes:
> [email protected] (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/
Miquel van Smoorenburg <[email protected]> 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
Richard Kettlewell <[email protected]> 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
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 --
[email protected]
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 - [email protected] - http://www.devcon.net
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 --
[email protected]
In article <[email protected]>,
Richard Kettlewell <[email protected]> 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.
Ville Herva <[email protected]> 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
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 --
[email protected]
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
Pavel Machek <[email protected]> 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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt