Your message dated Thu, 6 Nov 2008 11:31:21 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Fixed in 2.2.46
has caused the Debian Bug report #395161,
regarding does not properly dereference (relative) symlinks in subdirectories
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
395161: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395161
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: acl
Version: 2.2.41-1
Severity: important
File: /usr/bin/getfacl
Tags: upstream patch
This is an ugly little bug:
piper:~> touch file; mkdir dir; ln -s ../file dir/
piper:~> getfacl file >/dev/null && echo successful
successful
piper:~> cd dir
piper:~/dir> getfacl file >/dev/null && echo successful
successful
piper:~/dir> cd ../
piper:~> getfacl dir/file >/dev/null && echo successful
getfacl: dir/file: No such file or directory
I *think* this is because the symlink is relative:
readlink("dir/file", "../file", 4095) = 10
lstat("../file", 0x7fff10d8dbb0) = -1 ENOENT (No such file or directory)
it tries to access ../file from the current directory, not from the
directory. If I compare this to the strace of the stat utility, then
I can see that it calls lstat() on the given path and doesn't
actually use the result from readlink(), which is calls afterwards
probably to verify that it's a link we're dealing with:
lstat("dir/file", {st_mode=S_IFLNK|0777, st_size=7, ...}) = 0
[...]
readlink("dir/file", "../file", 8) = 7
[... no more references to dir/file or ../file]
Looking at the code of getfacl, I note the resolve_symlinks()
function in getfacl.c and can't help thinking that it does the wrong
thing. When walking trees, you do not want to resolve symlinks.
The attached patch removes the resolve_symlink call (but leaves the
function for now). A better solution may be to use the stat()
syscall instead of lstat()?
Anyway, with the patch applied, I tested:
- the above scenario, which now works
- mkdir dir dir2; touch dir2/file; ln -s ../dir2 dir; getfacl dir/dir2/file
- getfacl -R dir
==> which now only has one entry since symlinks don't have
ACLs.
- getfacl -R / (which was my original intention) :)
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-2-amd64
Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages acl depends on:
ii libacl1 2.2.41-1 Access control list shared library
ii libattr1 2.4.32-1 Extended attribute shared library
ii libc6 2.3.999.2-12 GNU C Library: Shared libraries
acl recommends no packages.
-- no debconf information
--
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
diff -Nru /tmp/QxLQw0kd5D/acl-2.2.41/debian/changelog
/tmp/FplFvruiTy/acl-2.2.41/debian/changelog
--- /tmp/QxLQw0kd5D/acl-2.2.41/debian/changelog 2006-07-21 01:37:53.000000000
+0200
+++ /tmp/FplFvruiTy/acl-2.2.41/debian/changelog 2006-10-25 11:24:28.000000000
+0200
@@ -1,3 +1,9 @@
+acl (2.2.41-1.1) unstable; urgency=low
+
+ * Fix gtefacl's tree-walk, which should not follow symlinks!
+
+ -- martin f. krafft <[EMAIL PROTECTED]> Wed, 25 Oct 2006 11:24:05 +0200
+
acl (2.2.41-1) unstable; urgency=low
* New upstream release
diff -Nru /tmp/QxLQw0kd5D/acl-2.2.41/getfacl/getfacl.c
/tmp/FplFvruiTy/acl-2.2.41/getfacl/getfacl.c
--- /tmp/QxLQw0kd5D/acl-2.2.41/getfacl/getfacl.c 2006-06-20
08:51:25.000000000 +0200
+++ /tmp/FplFvruiTy/acl-2.2.41/getfacl/getfacl.c 2006-10-25
11:23:42.000000000 +0200
@@ -617,11 +617,7 @@
const char *p;
__errors = 0;
- if ((p = resolve_symlinks(file)) == NULL) {
- fprintf(stderr, "%s: %s: %s\n", progname,
- xquote(file), strerror(errno));
- __errors++;
- } else if (nftw(p, __do_print, 0, opt_walk_logical? 0 : FTW_PHYS) < 0) {
+ if (nftw(file, __do_print, 0, opt_walk_logical? 0 : FTW_PHYS) < 0) {
fprintf(stderr, "%s: %s: %s\n", progname, xquote(file),
strerror(errno));
__errors++;
signature.asc
Description: Digital signature (GPG/PGP)
--- End Message ---
--- Begin Message ---
Package: acl
Version: 2.2.47-2
Hi,
it seems this bug was fixed in 2.2.46, where the entire recursive walking code
was rewritten (according to CVS logs). I can can confirm that it does not
occur anymore on current testing, version 2.2.47.
I'm taking the liberty of closing this bug.
Gr.
Matthijs
signature.asc
Description: Digital signature
--- End Message ---
