Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 223840 - [LSPP] getfacl fails to correctly display all information about links explicited as arguments
Summary: [LSPP] getfacl fails to correctly display all information about links explici...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: acl
Version: 5.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Thomas Woerner
QA Contact: David Lawrence
URL:
Whiteboard:
: 435403 (view as bug list)
Depends On:
Blocks: RHEL5LSPPCertTracker
TreeView+ depends on / blocked
 
Reported: 2007-01-22 18:22 UTC by Klaus Heinrich Kiwi
Modified: 2018-10-19 21:12 UTC (History)
6 users (show)

Fixed In Version: RHBA-2007-0511
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-11-07 16:43:33 UTC


Attachments (Terms of Use)
Thomas Woerner's patch (deleted)
2007-03-08 15:29 UTC, Klaus Weidner
no flags Details | Diff
New patch (deleted)
2007-03-09 17:37 UTC, Thomas Woerner
no flags Details
Improved walk patch (deleted)
2007-03-12 15:42 UTC, Thomas Woerner
no flags Details
Hopefully the last incarnation of this patch. (deleted)
2007-03-14 15:50 UTC, Thomas Woerner
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0511 normal SHIPPED_LIVE acl bug fix update 2007-10-30 15:45:17 UTC

Description Klaus Heinrich Kiwi 2007-01-22 18:22:17 UTC
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 20:04:39 UTC
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-25 01:20:56 UTC
This is blocking LSPP cert testing.

Comment 6 Irina Boverman 2007-02-14 20:40:20 UTC
per 2/12, Klaus Kiwi to propose correct behavior (see above).

Comment 7 Klaus Weidner 2007-02-19 02:29:11 UTC
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-23 03:57:20 UTC
acl-2.2.39-2 was built with a new patch to solve this problem.

Comment 9 Klaus Heinrich Kiwi 2007-02-26 12:34:45 UTC
(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-08 01:51:55 UTC
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 15:29:03 UTC
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 15:32:28 UTC
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 16:16:10 UTC
I am sorry, but where do you see a difference to the man page?

Comment 14 Thomas Woerner 2007-03-08 16:19:50 UTC
OK.. i see, "getfacl -dL l1" should return
# file: a
# owner: twoerner
# group: twoerner


Comment 15 Thomas Woerner 2007-03-09 17:37:29 UTC
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 14:11:18 UTC
(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 15:42:22 UTC
Created attachment 149829 [details]
Improved walk patch

Ok, I missed the symbolic link arguments. Fixed, now.

Comment 18 Klaus Heinrich Kiwi 2007-03-12 18:52:12 UTC
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 15:50:06 UTC
Created attachment 150058 [details]
Hopefully the last incarnation of this patch.

Please test with this patch.

Comment 20 Klaus Heinrich Kiwi 2007-03-14 20:43:13 UTC
everything looks beautiful now! Thanks for the patience and you may close the bug

Comment 21 Klaus Heinrich Kiwi 2007-03-14 20:45:28 UTC
Also, Steve, I think this will need a new .el5 package in your phc page.

thanks

Comment 24 Thomas Woerner 2007-03-21 13:57:39 UTC
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 22:18:42 UTC
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 16:43:33 UTC
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 13:14:19 UTC
*** 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.