$ 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