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)
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?)
This is blocking LSPP cert testing.
per 2/12, Klaus Kiwi to propose correct behavior (see above).
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
acl-2.2.39-2 was built with a new patch to solve this problem.
(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?
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.
Created attachment 149571 [details] Thomas Woerner's patch Thomas Woerner <twoerner> 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.)
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.)
I am sorry, but where do you see a difference to the man page?
OK.. i see, "getfacl -dL l1" should return # file: a # owner: twoerner # group: twoerner
Created attachment 149713 [details] New patch Please have a look at the new patch version. This should address all problems.
(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.
Created attachment 149829 [details] Improved walk patch Ok, I missed the symbolic link arguments. Fixed, now.
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
Created attachment 150058 [details] Hopefully the last incarnation of this patch. Please test with this patch.
everything looks beautiful now! Thanks for the patience and you may close the bug
Also, Steve, I think this will need a new .el5 package in your phc page. thanks
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
Verified the 2.2.39-2.1.el5 (x86_64) package and everything looks fine - you may close the bug.
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
*** Bug 435403 has been marked as a duplicate of this bug. ***