Very Computer

by **Doug Alcor** » Sun, 20 Jan 2002 06:20:15

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

--

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

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Xavier Beste** » Sun, 20 Jan 2002 06:30:18

> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Ville Herv** » Sun, 20 Jan 2002 20:20:09

On Fri, Jan 18, 2002 at 06:29:36PM -0800, you [H. Peter Anvin] said:

Quote:
> 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 --

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Miquel van Smoorenbur** » Sun, 20 Jan 2002 21:10:11

>> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Xavier Beste** » Sun, 20 Jan 2002 21:30:12

> > > 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Xavier Beste** » Sun, 20 Jan 2002 21:50:11

> > > > > 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Horst von Bran** » Mon, 21 Jan 2002 00:30:16

[...]

Quote:> > > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Mr. James W. Laferrier** » Mon, 21 Jan 2002 00:40:10

> [...]
> > 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Miquel van Smoorenbur** » Mon, 21 Jan 2002 03:00:16

According to Horst von Brand:

Quote:> > 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **christophe barb** » Mon, 21 Jan 2002 12:50:11

> > > 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

> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--

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 aisment.
Nicolas Boileau, L'Art potique

application_pgp-signature_part
< 1K Download

by **Andreas Ferbe** » Tue, 22 Jan 2002 05:50:13

> 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
---------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Ville Herv** » Tue, 22 Jan 2002 06:20:09

On Sun, Jan 20, 2002 at 09:44:31PM +0100, you [Andreas Ferber] claimed:

> > 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 --

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Pavel Mache** » Fri, 25 Jan 2002 07:50:11

Hi!

Quote:> >> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Herbert X** » Fri, 25 Jan 2002 18:50:12

>> 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/ )

Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Very Computer

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors

rm-ing files with open file descriptors