+++ This bug was initially created as a clone of Bug #660613 +++

Description of problem:

When the argument is a symbolic link to a directory, getfacl displays the attributes for the whole directory, despite option -h forbidding to follow the link.

Version-Release number of selected component (if applicable):

Fedora 14, acl-2.2.49-8, libacl-2.2.49-8

How reproducible:

Always

Steps to Reproduce:
1. mount with option user_xattr
2. create a target file in an inner directory (eg. src/target)
3. set an xattr ("setfattr -v blue -n user.color src/target")
4. create a symlink to the directory ("ln -s src symlink")
5. display the xattr of the symlink ("getfattr -h -e hex -n user.color symlink")
  
Actual results:

The symlink is followed and the contents of the target directory is examined

Expected results:

Per manual, the option -h prevents the symlink from being followed

Additional info:

--- Additional comment from jean-pierre.andre on 2010-12-07 11:54:12 CET ---

Oops, this is about getfattr, not getfacl, the versions are attr-2.4.44-5 and libattr-2.4.44-5

--- Additional comment from kdudka on 2010-12-07 18:31:15 CET ---

Thanks for reporting the bug!  It looks indeed broken to me.  The following patch fixes it:

diff --git a/libmisc/walk_tree.c b/libmisc/walk_tree.c
--- a/libmisc/walk_tree.c
+++ b/libmisc/walk_tree.c
@@ -60,7 +60,8 @@ static int walk_tree_rec(const char *path, int walk_flags,
                                     void *), void *arg, int depth)
 {
        int follow_symlinks = (walk_flags & WALK_TREE_LOGICAL) ||
-                             (!(walk_flags & WALK_TREE_PHYSICAL) &&
+                             ((walk_flags & WALK_TREE_DEREFERENCE) &&
+                              !(walk_flags & WALK_TREE_PHYSICAL) &&
                               depth == 0);
        int have_dir_stat = 0, flags = walk_flags, err;
        struct entry_handle dir;

I'll prepare some regression test and post it on the upstream ML.

--- Additional comment from jean-pierre.andre on 2010-12-07 21:43:26 CET ---

Behaves as expected with fix applied. Thanks.

--- Additional comment from agruen on 2010-12-15 02:49:55 CET ---

What kernel version did you test this on?  I'm getting the following buggy 
result from "getfattr -h -n user.color link" with Kamil's fix:

  getxattr("link", "user.color", 0x0, 0) = -1 EPERM (Operation not permitted)

This shouldn't be; we should be getting -ENODATA here.  This seems to be due to a bug in kernel commit f1f2d871l whic hfirst showed up in v2.6.19-rc5.  I'm currently testing a fix for that.

--- Additional comment from jean-pierre.andre on 2010-12-15 09:57:47 CET ---

I also get the EPERM (kernel 2.6.35.6-48, attr 2.4.44-5) both with unpatched attr or patched as suggested by Kamil.

$ touch target
$ ln -s target symlink
$ getfattr -h -e hex -n user.color symlink
symlink: user.color: Operation not permitted
$ strace getfattr -h -e hex -n user.color symlink
[...]
lstat("symlink", {st_mode=S_IFLNK|0777, st_size=6, ...}) = 0
lgetxattr("symlink", "user.color", 0x0, 0) = -1 EPERM (Operation not permitted)

Same result for a symlink to a directory (also when requested by root).
This appears as specific to the user name space. In the system name space, I get the expected result (this is with patched attr, otherwise the full directory is examined). The above was on ext3, below is on ntfs.

$ ls -l "/vista/Documents and Settings"
lrwxrwxrwx 2 root root 60 Nov  2  2006 /vista/Documents and Settings -> /vista/Users
$ getfattr -e hex -n system.ntfs_object_id "/vista/Documents and Settings"
/vista/Documents and Settings: system.ntfs_object_id: No such attribute
$ strace getfattr -e hex -n system.ntfs_object_id "/vista/Documents and Settings"
getxattr("/vista/Documents and Settings", "system.ntfs_object_id", 0x0, 0) = -1 ENODATA (No data available)

--- Additional comment from jean-pierre.andre on 2010-12-15 10:06:40 CET ---

I should have put a -h in the last example in my previous post. Here it is :

strace getfattr -h -e hex -n system.ntfs_object_id "/vista/Documents and Settings"
lgetxattr("/vista/Documents and Settings", "system.ntfs_object_id", 0x0, 0) = -1 ENODATA (No data available)

--- Additional comment from kdudka on 2010-12-22 14:49:47 CET ---

Right, I am running 2.6.35.6-48.fc14.x86_64 and also getting EPERM on the symlink.  But we should definitely not follow symlinks when -h is given.  So the fix for getfattr goes the right direction I think.

Note the reproducer from comment #5 did not repeat the original bug for me,  the reproducer from comment #0 did.  The bug is specific to directory tree traversal.

--- Additional comment from kdudka on 2010-12-22 15:49:06 CET ---

fixed in attr-2.4.44-6.fc15