Bug 223840 - [LSPP] getfacl fails to correctly display all information about links explicited as arguments
[LSPP] getfacl fails to correctly display all information about links explici...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: acl (Show other bugs)
5.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Thomas Woerner
David Lawrence
:
: 435403 (view as bug list)
Depends On:
Blocks: RHEL5LSPPCertTracker 227613
  Show dependency treegraph
 
Reported: 2007-01-22 13:22 EST by Klaus Heinrich Kiwi
Modified: 2010-10-22 04:08 EDT (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2007-0511
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 11:43:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Thomas Woerner's patch (3.91 KB, patch)
2007-03-08 10:29 EST, Klaus Weidner
no flags Details | Diff
New patch (5.06 KB, text/x-patch)
2007-03-09 12:37 EST, Thomas Woerner
no flags Details
Improved walk patch (5.14 KB, text/x-patch)
2007-03-12 11:42 EDT, Thomas Woerner
no flags Details
Hopefully the last incarnation of this patch. (5.23 KB, text/x-patch)
2007-03-14 11:50 EDT, Thomas Woerner
no flags Details

  None (edit)
Description Klaus Heinrich Kiwi 2007-01-22 13:22:17 EST
Description of problem:
create a directory, setfacl some permissions on it. List this permissions.
Create a link to this directory. getfacl on this link (the link should be
explicit as a parameter). Results differ when querying the dir directly and when
querying the link - per manual, the output should be the same

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

How reproducible:
everytime

Steps to Reproduce:
[root@alex test]# mkdir d
[root@alex test]# umask 022
[root@alex test]# mkdir d/d
[root@alex test]# setfacl -nm u:daemon:rx,d:u:daemon:rx,g:users:rx,g:daemon:rwx d/d
[root@alex test]# getfacl d/d
# file: d/d
# owner: root
# group: root
user::rwx
user:daemon:r-x
group::r-x
group:daemon:rwx                #effective:r-x
group:users:r-x
mask::r-x
other::r-x
default:user::rwx
default:user:daemon:r-x
default:group::r-x
default:mask::r-x
default:other::r-x

[root@alex test]# ln -s d d/l
[root@alex test]# getfacl d/l
# file: d
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

  
Actual results:
[root@alex test]# getfacl d/l
# file: d
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Expected results:
[root@alex test]# getfacl d/l
# file: d/d
# owner: root
# group: root
user::rwx
user:daemon:r-x
group::r-x
group:daemon:rwx                #effective:r-x
group:users:r-x
mask::r-x
other::r-x
default:user::rwx
default:user:daemon:r-x
default:group::r-x
default:mask::r-x
default:other::r-x

Additional info:
This is required for lspp certification. Don't know if it's related to #173178
(updated that bug too, please take a look)
Comment 1 Klaus Heinrich Kiwi 2007-01-22 15:04:39 EST
Another example of 'incorrect' link manipulation:

---procedure---
[root@alex klausk]# touch a
[root@alex klausk]# ln -s a l1
[root@alex klausk]# ln -s l1 l2
[root@alex klausk]# ls -l
total 12
-rw-r--r-- 1 root root 0 Jan 22 10:51 a
lrwxrwxrwx 1 root root 1 Jan 22 10:51 l1 -> a
lrwxrwxrwx 1 root root 2 Jan 22 10:51 l2 -> l1

---current results----
[root@alex klausk]# getfacl -dRL l2
# file: l1
# owner: root
# group: root


---expected results---
[root@alex klausk]# getfacl -dRL l2
# file: a
# owner: root
# group: root

(the above means: shouldn't the '-L' option to getfacl do recursive link-lookup?)
Comment 2 Irina Boverman 2007-01-24 20:20:56 EST
This is blocking LSPP cert testing.
Comment 6 Irina Boverman 2007-02-14 15:40:20 EST
per 2/12, Klaus Kiwi to propose correct behavior (see above).
Comment 7 Klaus Weidner 2007-02-18 21:29:11 EST
This is not a blocker for LSPP testing as long as the underlying system calls
(which are the actual security relevant interface) work correctly. This is just
an issue of a userspace tool behaving a bit oddly, but that in itself would not
be a blocker issue.

More reports related to this bug:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173178

Please make the following bug public, I can only access the IBM mirrored version
of that:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128265
https://bugzilla.linux.ibm.com/show_bug.cgi?id=10104
Comment 8 Steve Grubb 2007-02-22 22:57:20 EST
acl-2.2.39-2 was built with a new patch to solve this problem.
Comment 9 Klaus Heinrich Kiwi 2007-02-26 07:34:45 EST
(In reply to comment #8)
> acl-2.2.39-2 was built with a new patch to solve this problem.

Is there a .el5 package available?
Comment 10 Klaus Heinrich Kiwi 2007-03-07 20:51:55 EST
With acl-2.2.39-2.el5 the behavior changed, but still not seeing the expected
results:

<first testcase, comment #0>
[root/abat_r/SystemLow@oracer5 teste]# mkdir d
[root/abat_r/SystemLow@oracer5 teste]# umask 022
[root/abat_r/SystemLow@oracer5 teste]# mkdir d/d
[root/abat_r/SystemLow@oracer5 teste]# setfacl -nm
u:daemon:rx,d:u:daemon:rx,g:users:rx,g:daemon:rwx d/d
[root/abat_r/SystemLow@oracer5 teste]# getfacl d/d
# file: d/d
# owner: root
# group: root
user::rwx
user:daemon:r-x
group::r-x
group:daemon:rwx                #effective:r-x
group:users:r-x
mask::r-x
other::r-x
default:user::rwx
default:user:daemon:r-x
default:group::r-x
default:mask::r-x
default:other::r-x

[root/abat_r/SystemLow@oracer5 teste]# ln -s d d/l
[root/abat_r/SystemLow@oracer5 teste]# getfacl d/l
# file: d/l
# owner: root
# group: root
user::rwx
user:daemon:r-x
group::r-x
group:daemon:rwx                #effective:r-x
group:users:r-x
mask::r-x
other::r-x


<second testcase, comment #1>
[root/abat_r/SystemLow@oracer5 ~]# touch a
[root/abat_r/SystemLow@oracer5 ~]# ln -s a l1
[root/abat_r/SystemLow@oracer5 ~]# ln -s a l2
[root/abat_r/SystemLow@oracer5 ~]# getfacl -d l2
# file: l2
# owner: root
# group: root
[root/abat_r/SystemLow@oracer5 ~]# getfacl -d l1
# file: l1
# owner: root
# group: root


In both cases I expect (per manual page) that the link gets followed if I
specify the '-L' parameter of if the link is exposed directly as an argument
(different from when some link is hit inside a directory in a recursive query)

Please tell me if my interpretation of the manual page is incorrect.

Another option, since this is not a required functionality and the behavior now
seems consistent with 'never follow any links', is to change the man page and
leave things as they are.

cc Klaus W. for any comments since he is the patch author.
Comment 11 Klaus Weidner 2007-03-08 10:29:03 EST
Created attachment 149571 [details]
Thomas Woerner's patch

Thomas Woerner <twoerner@redhat.com> mailed this patch to Steve Grubb who
forwarded it to me. It's supposed to be the one that's in the new "acl"
version: http://people.redhat.com/sgrubb/files/lspp/acl-2.2.39-2.el5.src.rpm

(I'm not the author of this patch, I'm just adding it to the Bugzilla entry for
completeness.)
Comment 12 Klaus Weidner 2007-03-08 10:32:28 EST
re comment #10: I'm not the author of this version of the patch. I think the new
behavior is ok and the man page should be fixed to reflect how it actually works.

(As I had previously said I don't have a strong opinion about how the tool
should work, it should just behave consistently and not depend on the low-level
ordering of entries in the directory.)
Comment 13 Thomas Woerner 2007-03-08 11:16:10 EST
I am sorry, but where do you see a difference to the man page?
Comment 14 Thomas Woerner 2007-03-08 11:19:50 EST
OK.. i see, "getfacl -dL l1" should return
# file: a
# owner: twoerner
# group: twoerner
Comment 15 Thomas Woerner 2007-03-09 12:37:29 EST
Created attachment 149713 [details]
New patch

Please have a look at the new patch version. This should address all problems.
Comment 16 Klaus Heinrich Kiwi 2007-03-12 10:11:18 EDT
(In reply to comment #15)
> Created an attachment (id=149713) [edit]
> New patch
> 
> Please have a look at the new patch version. This should address all problems.

Applied new patch on top of acl-2.2.39-1.1.src.rpm, but results seems to be the
same as release 2:


Previous results from first testcase:
>[root/abat_r/SystemLow@oracer5 teste]# getfacl d/l
># file: d/l
># owner: root
># group: root
>user::rwx
>user:daemon:r-x
>group::r-x
>group:daemon:rwx                #effective:r-x
>group:users:r-x
>mask::r-x
>other::r-x


actual results:
[root/abat_r/SystemLow@oracer5 teste2]# getfacl d/l
# file: d/l
# owner: root
# group: root
user::rwx
user:daemon:r-x
group::r-x
group:daemon:rwx                #effective:r-x
group:users:r-x
mask::r-x
other::r-x

[root/abat_r/SystemLow@oracer5 teste2]#                                       


second testcase also shows the same results.
Comment 17 Thomas Woerner 2007-03-12 11:42:22 EDT
Created attachment 149829 [details]
Improved walk patch

Ok, I missed the symbolic link arguments. Fixed, now.
Comment 18 Klaus Heinrich Kiwi 2007-03-12 14:52:12 EDT
Ok, fir(In reply to comment #17)
> Created an attachment (id=149829) [edit]
> Improved walk patch
> 
> Ok, I missed the symbolic link arguments. Fixed, now.

First testcase seems fine now..

Am not entirely sure about the second:

[root/abat_r/SystemLow@oracer5 teste]# touch a
[root/abat_r/SystemLow@oracer5 teste]# ln -s a l1
[root/abat_r/SystemLow@oracer5 teste]# ln -s l1 l2
[root/abat_r/SystemLow@oracer5 teste]# getfacl -dRL l2
# file: l1
# owner: root
# group: root

[root/abat_r/SystemLow@oracer5 teste]#


Was expecting that even specifying '-L' or the link directly, getfacl should
follow the link through more than the first level, and finally print the 'end'
target file.

Is this the desired behavior or am I mis-interpreting things?

thanks,

 Klaus
Comment 19 Thomas Woerner 2007-03-14 11:50:06 EDT
Created attachment 150058 [details]
Hopefully the last incarnation of this patch.

Please test with this patch.
Comment 20 Klaus Heinrich Kiwi 2007-03-14 16:43:13 EDT
everything looks beautiful now! Thanks for the patience and you may close the bug
Comment 21 Klaus Heinrich Kiwi 2007-03-14 16:45:28 EDT
Also, Steve, I think this will need a new .el5 package in your phc page.

thanks
Comment 24 Thomas Woerner 2007-03-21 09:57:39 EDT
There is a new package with an slightly enhanced patch (fixed getfacl exit codes)

Please have a look at acl-2.2.39-2.1.el5

Thanks, Thomas
Comment 25 Klaus Heinrich Kiwi 2007-03-26 18:18:42 EDT
Verified the 2.2.39-2.1.el5 (x86_64) package and everything looks fine - you may
close the bug.
Comment 29 errata-xmlrpc 2007-11-07 11:43:33 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0511.html
Comment 31 Jiri Moskovcak 2008-04-10 09:14:19 EDT
*** Bug 435403 has been marked as a duplicate of this bug. ***

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