Bug 660613
| Summary: | getfattr follows the links despite option -h | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jean-Pierre André <jean-pierre.andre> | |
| Component: | attr | Assignee: | Kamil Dudka <kdudka> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | high | Docs Contact: | ||
| Priority: | low | |||
| Version: | 14 | CC: | agruen, jscotka, kdudka, steved | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | attr-2.4.44-4.fc13 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 665049 (view as bug list) | Environment: | ||
| Last Closed: | 2011-01-17 20:49:53 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 665049 | |||
Oops, this is about getfattr, not getfacl, the versions are attr-2.4.44-5 and libattr-2.4.44-5 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.
Behaves as expected with fix applied. Thanks. 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.
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)
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)
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. fixed in attr-2.4.44-6.fc15 proposed upstream: http://lists.gnu.org/archive/html/acl-devel/2010-12/msg00003.html 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 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 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 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. 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. |
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: