lkml.org 
[lkml]   [1998]   [Sep]   [8]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateTue, 8 Sep 1998 12:40:46 +0930 (CST)
FromAlan Modra <>
Subjectsymlinks and linux 2.1.120
symlinks on NFS are behaving strangely.  The following illustrates a
simple way to trash directory link counts.

$ mkdir a; mkdir a/b; ln -s b a/c; ls -la a
total 4
drwxrwxr-x   3 root     root          512 Sep  8 10:55 .
drwxrwxr-x   4 root     root          512 Sep  8 10:55 ..
drwxrwxr-x   2 root     root          512 Sep  8 10:55 b
lrwxrwxrwx   1 root     root            1 Sep  8 10:55 c -> b
$ cp -ldpr a z; ls -la z
total 4
drwxrwxr-x   4 root     root          512 Sep  8 10:55 .
drwxrwxr-x   5 root     root          512 Sep  8 10:57 ..
drwxrwxr-x   2 root     root          512 Sep  8 10:55 b
drwxrwxr-x   3 root     root          512 Sep  8 10:57 c
$ rm -rf z
rm: z/c: Directory not empty
rm: z: Directory not empty


"strace cp -ldpr a z" doesn't show anything unusual, just that link() is
called for the symlink.

lstat("a/c", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
link("a/c", "z/c")                      = 0

Doing the same on an ext2 filesystem gives

$ cp -ldpr a z
cp: cannot create link `z/c': Operation not permitted


I'm guessing that this is due to KAB's symlink security patch to
fs/namei.c.  What awful catastrophic security hole is being closed here?
Does it really warrant breaking such a common cp operation?  If so, then
nfs (and other FSs?) need fixing to disallow the link, and GNU fileutils
also needs a small fix.


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

\
 
 \ /
  Last update: 2005-03-22 12:44    [from the cache]
©2003-2008