Bug 692982 - [RFE] add function acl_extended_file_nofollow()
[RFE] add function acl_extended_file_nofollow()
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: acl (Show other bugs)
14
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kamil Dudka
Fedora Extras Quality Assurance
: Patch
Depends On:
Blocks: 692823 719607 720318 720325 733978 733979
  Show dependency treegraph
 
Reported: 2011-04-01 17:15 EDT by Kamil Dudka
Modified: 2011-08-28 22:58 EDT (History)
4 users (show)

See Also:
Fixed In Version: acl-2.2.49-9.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 692823
: 720318 (view as bug list)
Environment:
Last Closed: 2011-07-18 18:37:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kamil Dudka 2011-04-01 17:15:37 EDT
+++ This bug was initially created as a clone of Bug #692823 +++

Description of problem:

/bin/ls -l on an automount directory of some nature peforms the following ops on each file:

lstat("doc", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
lgetxattr("doc", "security.selinux", "unconfined_u:object_r:default_t:s0", 255) = 35
getxattr("doc", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)

and possibly also:

getxattr("/etc", "system.posix_acl_default", 0x0, 0) = -1 ENODATA (No data available)

depending on the circumstances.

The first two calls (lstat and lgetxattr) don't follow symlinks and mounts, but the second is a getxattr call which _does_ follow symlinks and mounts.  The latter can cause automount points to mount, which the former won't, at least from linux-2.6.38-rc1 onwards.

These should be consistent, and so I believe the getxattr calls should be lgetxattr calls.  Without this, the first two calls may refer to a different object to the second pair of calls.

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

F-13 and F-14 coreutils both show this.  coreutils-8.5-7.fc14.x86_64 is what's on my desktop.

How reproducible:

100%

Steps to Reproduce:
1. strace -e trace=lstat,getxattr,lgetxattr ls -l /media
  
Actual results:

lstat("/media", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lgetxattr("/media", "security.selinux", "system_u:object_r:mnt_t:s0", 255) = 27
getxattr("/media", "system.posix_acl_access", 0x0, 0) = -1 ENODATA (No data available)
getxattr("/media", "system.posix_acl_default", 0x0, 0) = -1 ENODATA (No data available)

Expected results:

The getxattrs should be lgetxattrs.

Additional info:

This is a problem that occurs in conjunction with the acl package - that doesn't provide a way of calling lgetxattr() through it.

--- Additional comment from ovasik on 2011-04-01 12:25:24 CEST ---

coreutils (gnulib) just uses acl_extended_file from libacl - which actually does the getxattr calls. Reassigning to acl package.

--- Additional comment from kdudka on 2011-04-01 12:46:46 CEST ---

There is not much we can do with acl_extended_file().  Symlinks are always followed when setting/getting ACLs, because they can have no ACLs themselves.  The only choice I see is to either not call acl_extended_file() for symlinks, or use acl_extended_fd(), which is not applicable on symlinks by definition.

--- Additional comment from ovasik on 2011-04-01 13:16:10 CEST ---

File_has_acl() gnulib function already calls libacl acl_extended_file() only for non-symlinks ...
But as discussed of bugzilla, it really looks it can't be fixed in libacl and coreutils is probably the right place.

--- Additional comment from dhowells on 2011-04-01 15:48:48 CEST ---

The files in question are not symlinks; they are directories with follow_link semantics in the kernel (or the equivalent in 2.6.38+).

You also cannot simply look at the filesystem the target file is on and ask "is it autofs?".  The filesystem may be nfs4 (referrals), cifs (DFS junction point) or afs (volume mount point), and more may follow.  Currently, you cannot tell if it's an automount point or not.

I would think there needs to be a version of acl_extended_file() that calls lgetxattr().  If that doesn't work because the file is a symlink and thus has no ACL, then ls can use acl_extended_file() if -L was passed to it or if it's going to dereference it anyway.

--- Additional comment from dhowells on 2011-04-01 16:56:23 CEST ---

> There is no call of l?etxattr() in the whole acl library.  Does any other ACL
> implementation have such ability?

MacOS X's getxattr() can take a XATTR_NOFOLLOW flag that has the same effect as using lgetxattr().

Also, isn't acl_extended_file() a Linux extension?  Would it be that hard to add an acl_extended_file_nofollow() or something?

--- Additional comment from kdudka on 2011-04-01 17:39:48 CEST ---

(In reply to comment #7)
> Also, isn't acl_extended_file() a Linux extension?  Would it be that hard to
> add an acl_extended_file_nofollow() or something?

Andreas, is addition of such a new function to libacl acceptable by upstream?
The problem here is that acl_extended_file() triggers a mount even when not necessary.

--- Additional comment from agruen on 2011-04-01 19:35:51 CEST ---

I don't see what we can do to fix this other than not using acl_extended_file() in file_has_acl().  We could either add and use acl_extended_file_nofollow() there or put that code directly into gnulib; the code required is quite trivial and just as Linux specific as acl_extended_file().

Which of the two would you prefer?

--- Additional comment from kdudka on 2011-04-01 20:01:01 CEST ---

I'd prefer to create a new function in libacl such that we maintain all the code aware of the acl->xattr mapping at a single place.  If such a new function is acceptable, I'll send a patch to acl-devel.

--- Additional comment from agruen on 2011-04-01 23:02:17 CEST ---

That should work, thanks.

I'm adding Jim; this should be relevant for him, too.
Comment 1 Kamil Dudka 2011-04-04 08:08:39 EDT
proposed upstream:

http://lists.gnu.org/archive/html/acl-devel/2011-04/msg00000.html
Comment 3 Kamil Dudka 2011-04-05 20:51:13 EDT
I can see both patches (the original one + Andreas' fixes to that) in the upstream git repository:

http://git.savannah.gnu.org/cgit/acl.git/commit/?id=6bf5e24
http://git.savannah.gnu.org/cgit/acl.git/commit/?id=ad4ca5a

I'll prepare a rawhide build of acl with them later today.
Comment 4 Kamil Dudka 2011-04-06 08:04:01 EDT
built as acl-2.2.49-11.fc16
Comment 5 Fedora Admin XMLRPC Client 2011-04-21 10:50:22 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 6 Fedora Update System 2011-07-08 07:33:55 EDT
acl-2.2.49-11.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/acl-2.2.49-11.fc15
Comment 7 Fedora Update System 2011-07-08 07:35:32 EDT
acl-2.2.49-9.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/acl-2.2.49-9.fc14
Comment 8 Fedora Update System 2011-07-08 14:08:10 EDT
Package acl-2.2.49-9.fc14:
* should fix your issue,
* was pushed to the Fedora 14 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing acl-2.2.49-9.fc14'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/acl-2.2.49-9.fc14
then log in and leave karma (feedback).
Comment 9 Fedora Update System 2011-07-18 18:37:39 EDT
acl-2.2.49-11.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 10 Fedora Update System 2011-07-25 23:36:46 EDT
acl-2.2.49-9.fc14 has been pushed to the Fedora 14 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.