Your message dated Sun, 18 Feb 2007 15:08:07 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#238375: xutils: [lndir] can create incorrect links because
it uses stat() instead of lstat()
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Version: 1.0.1-1
This has been fixed upstream 2 years ago in
http://gitweb.freedesktop.org/?p=xorg/util/lndir.git;a=commit;h=f147e94b91751af67000a29ba59d7cd94f163df6
The test sequence provided by the submitter now works fine.
Brice
--- End Message ---
