Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 660613 - getfattr follows the links despite option -h
Summary: getfattr follows the links despite option -h
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: attr
Version: 14
Hardware: Unspecified
OS: Linux
low
high
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 665049
TreeView+ depends on / blocked
 
Reported: 2010-12-07 10:36 UTC by Jean-Pierre André
Modified: 2011-07-19 15:41 UTC (History)
4 users (show)

Fixed In Version: attr-2.4.44-4.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 665049 (view as bug list)
Environment:
Last Closed: 2011-01-17 20:49:53 UTC
Type: ---


Attachments (Terms of Use)

Description Jean-Pierre André 2010-12-07 10:36:53 UTC
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:

Comment 1 Jean-Pierre André 2010-12-07 10:54:12 UTC
Oops, this is about getfattr, not getfacl, the versions are attr-2.4.44-5 and libattr-2.4.44-5

Comment 2 Kamil Dudka 2010-12-07 17:31:15 UTC
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.

Comment 3 Jean-Pierre André 2010-12-07 20:43:26 UTC
Behaves as expected with fix applied. Thanks.

Comment 4 Andreas Gruenbacher 2010-12-15 01:49:55 UTC
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.

Comment 5 Jean-Pierre André 2010-12-15 08:57:47 UTC
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)

Comment 6 Jean-Pierre André 2010-12-15 09:06:40 UTC
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)

Comment 7 Kamil Dudka 2010-12-22 13:49:47 UTC
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.

Comment 8 Kamil Dudka 2010-12-22 14:49:06 UTC
fixed in attr-2.4.44-6.fc15

Comment 9 Kamil Dudka 2010-12-22 16:51:04 UTC
proposed upstream:

http://lists.gnu.org/archive/html/acl-devel/2010-12/msg00003.html

Comment 10 Fedora Update System 2011-01-05 18:58:25 UTC
attr-2.4.44-6.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/attr-2.4.44-6.fc14

Comment 11 Fedora Update System 2011-01-05 18:58:48 UTC
attr-2.4.44-4.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/attr-2.4.44-4.fc13

Comment 12 Fedora Update System 2011-01-06 19:26:50 UTC
attr-2.4.44-4.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update attr'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/attr-2.4.44-4.fc13

Comment 13 Fedora Update System 2011-01-17 20:49:33 UTC
attr-2.4.44-6.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2011-01-23 20:25:18 UTC
attr-2.4.44-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.