Package: xutils
Version: 4.1.0-16woody3
Severity: normal
Tags: patch
(xutils seems to own lndir; why is that?)
I discovered a flaw in lndir.
First, please observe the following, correct, behaviour.
[EMAIL PROTECTED]:~$ mkdir sourcedir; cd sourcedir
[EMAIL PROTECTED]:~/sourcedir$ mkdir dir1 dir2; touch file1
[EMAIL PROTECTED]:~/sourcedir$ ln -s file1 linktofile1
[EMAIL PROTECTED]:~/sourcedir$ ln -s dir1 linktodir1
[EMAIL PROTECTED]:~/sourcedir$ ls -lG
total 8
drwxr-xr-x 2 clown 4096 Mar 16 20:05 dir1
drwxr-xr-x 2 clown 4096 Mar 16 20:05 dir2
-rw-r--r-- 1 clown 0 Mar 16 20:05 file1
lrwxrwxrwx 1 clown 4 Mar 16 20:05 linktodir1 -> dir1
lrwxrwxrwx 1 clown 5 Mar 16 20:05 linktofile1 -> file1
[EMAIL PROTECTED]:~/sourcedir$ cd ..; mkdir targetdir; cd targetdir
[EMAIL PROTECTED]:~/targetdir$ lndir ../sourcedir
../sourcedir/dir1:
../sourcedir/dir2:
[EMAIL PROTECTED]:~/targetdir$ ls -lG; cd ..
total 8
drwxr-xr-x 2 clown 4096 Mar 16 20:06 dir1
drwxr-xr-x 2 clown 4096 Mar 16 20:06 dir2
lrwxrwxrwx 1 clown 18 Mar 16 20:06 file1 ->
../sourcedir/file1
lrwxrwxrwx 1 clown 4 Mar 16 20:06 linktodir1 -> dir1
lrwxrwxrwx 1 clown 5 Mar 16 20:06 linktofile1 -> file1
This is the correct behaviour of lndir.
However, things will go wrong when the sequence of creation is a bit
changed:
[EMAIL PROTECTED]:~$ mkdir sourcedir2; cd sourcedir2
[EMAIL PROTECTED]:~/sourcedir2$ mkdir dir1; touch file1
[EMAIL PROTECTED]:~/sourcedir2$ ln -s file1 linktofile1
[EMAIL PROTECTED]:~/sourcedir2$ ln -s dir1 linktodir1
[EMAIL PROTECTED]:~/sourcedir2$ mkdir dir2
[EMAIL PROTECTED]:~/sourcedir2$ ls -lG
total 8
drwxr-xr-x 2 clown 4096 Mar 16 20:13 dir1
drwxr-xr-x 2 clown 4096 Mar 16 20:13 dir2
-rw-r--r-- 1 clown 0 Mar 16 20:13 file1
lrwxrwxrwx 1 clown 4 Mar 16 20:13 linktodir1 -> dir1
lrwxrwxrwx 1 clown 5 Mar 16 20:13 linktofile1 -> file1
[EMAIL PROTECTED]:~/sourcedir2$ cd ..; mkdir targetdir2; cd targetdir2
[EMAIL PROTECTED]:~/targetdir2$ lndir ../sourcedir2
../sourcedir2/dir1:
../sourcedir2/linktodir1:
[EMAIL PROTECTED]:~/targetdir2$ ls -lG
total 8
drwxr-xr-x 2 clown 4096 Mar 16 20:15 dir1
lrwxrwxrwx 1 clown 18 Mar 16 20:15 dir2 ->
../sourcedir2/dir2
lrwxrwxrwx 1 clown 19 Mar 16 20:15 file1 ->
../sourcedir2/file1
drwxr-xr-x 2 clown 4096 Mar 16 20:15 linktodir1
lrwxrwxrwx 1 clown 5 Mar 16 20:15 linktofile1 -> file1
[EMAIL PROTECTED]:~/targetdir2$
This is totally wrong!
- dir2 now falsely is a symlink to ../sourcedir2/dir2
- linktodir1 now falsely has become a directory
I have attached a patch for lndir.c which solves the problem (for me).
It all bowls does to the fact that the stat() function behaves in a way
that if the mentioned filename is a link, stat() will dereference it.
lstat() won't dereference it; the link itself is stat-ed (man 2 stat).
If not sure if this is good for upstream as will since lstat() might not
be available everywhere. Furthermore, there already seems to be some
sort of check later on (lines 235-239) but IMHO this is way too late.
I guess it needs further investigation.
--- lndir.c.orig 2004-03-16 20:21:33.000000000 +0100
+++ lndir.c 2004-03-16 20:55:21.000000000 +0100
@@ -192,9 +192,11 @@
strcpy (p, dp->d_name);
if (n_dirs > 0) {
- if (stat (buf, &sb) < 0) {
- mperror (buf);
- continue;
+ if (lstat (buf, &sb) < 0) {
+ if (stat (buf, &sb) < 0) {
+ mperror (buf);
+ continue;
+ }
}
#ifdef S_ISDIR
Note that this problem might also not occur when the filesystem 'below'
the readdir() on line 183 _first_ returns all directories, followed by
files/symlinks. I am not aware of these filesystems but I'm sure they
exist; I ran these examples on ext3.
I checked 4.2.1 as well and it is flawed also.
Regards,
Marc.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux frodo 2.4.24meaculpa #1 Mon Jan 19 21:16:54 CET 2004 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages xutils depends on:
ii libc6 2.2.5-11.5 GNU C Library: Shared libraries an
ii libncurses5 5.2.20020112a-7 Shared libraries for terminal hand
ii xfree86-common 4.1.0-16woody3 X Window System (XFree86) infrastr
ii zlib1g 1:1.1.4-1.0woody0 compression library - runtime
