bugacl - Bugs: bug #28131, setfacl --physical mode does not...

 
 

bug #28131: setfacl --physical mode does not work

Submitted by:  Markus Steinborn <msteinbo>
Submitted on:  Mon 30 Nov 2009 02:29:24 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 22 Jan 2010 11:54:37 PM UTC, comment #3:

Good catch. Thanks for the patch. Added to git:
http://git.savannah.gnu.org/cgit/acl.git/commit/?id=d539830d19b35df0c12c0b7d36c1f6c428f34a91

Brandon Philips <philips>
Project Administrator
Sat 26 Dec 2009 12:40:32 PM UTC, comment #2:

Well,

fixing the bug in the same way as

http://git.savannah.gnu.org/cgit/acl.git/commit/?id=63451a0

but this time for setfacl seems to be correct.

But it remains the question why walk_tree_rec decides not to follow symlinks (by setting "follow_symlinks" to 0, and then follows them...

(file #19363)

Markus Steinborn <msteinbo>
Sat 26 Dec 2009 09:54:11 AM UTC, comment #1:

I took a deeper look at the source code. Assume setfacl
is called as above.

After processing the options, the function walk_tree_rec (file:
libmisc/walk_tree.c) is called with path ".". A little time later, the same function is called with path "2", which is a symlink.

In line 62 of libmisc/walk_tree.c, it is decided not to follow symlinks (that is correct!). In line 77, lstat(...) is called on the symlink "2".

The conditions in line 79 and line 81 are true, so on line 84 stat(...) is called on the symlink "2". Note that "2" is a dangling symlink in my example (otherwise "ls" would have listed a file named "1"), so stat() failes, because stat follows symlinks in contrast to lstat(). This failure is returned to the
caller on line 85.

Please comment the attached patch.

(file #19362)

Markus Steinborn <msteinbo>
Mon 30 Nov 2009 02:29:24 PM UTC, original submission:

On https://bugzilla.redhat.com/show_bug.cgi?id=488674 I found the following bug, which is always reproduible:

--- cut here ---
msteinbo@acer:/tmp/2>ls -l
insgesamt 0
lrwxrwxrwx 1 msteinbo msteinbo 1 30. Nov 15:21 2 -> 1
msteinbo@acer:/tmp/2>LANG=C ../acl-2.2.49/setfacl/setfacl -RP -m u:bin:r .
lt-setfacl: ./2: No such file or directory
msteinbo@acer:/tmp/2>echo $?
1
--- cut here ---

As you see, version 2.2.49 does not fix this bug.

With version 2.2.39 you get the expected results:

--- cut here ---
msteinbo@acer:/tmp/2>ls -l
insgesamt 0
lrwxrwxrwx 1 msteinbo msteinbo 1 30. Nov 15:21 2 -> 1
msteinbo@acer:/tmp/2>setfacl -RP -m u:bin:r .
msteinbo@acer:/tmp/2>echo $?
0
--- cut here ---

Markus Steinborn <msteinbo>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #19363:  setfacl.patch added by msteinbo (1KiB - text/x-patch - New patch, replacing (?) the old one)
file #19362:  acl-physical-walk.patch added by msteinbo (823B - text/x-patch - Proposed patch to fix the bug.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by philips (Posted a comment)
  • -unavailable- added by msteinbo (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 22 Jan 2010 11:54:37 PM UTCphilipsOpen/ClosedOpen=>Closed
    Sat 26 Dec 2009 12:40:32 PM UTCmsteinboAttached File-=>Added setfacl.patch, #19363
    Sat 26 Dec 2009 09:54:11 AM UTCmsteinboAttached File-=>Added acl-physical-walk.patch, #19362

    Back to the top


    Powered by Savane 3.1-cleanup1