Bug 467936
| Summary: | getfacl/setfacl remove SUID/SGID/Sticky-Bits | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | M. Steinborn <gnugv_maintainer> | ||||||
| Component: | acl | Assignee: | Kamil Dudka <kdudka> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | rawhide | CC: | brandon, bruno.cornec, gnugv_maintainer, jmoskovc, ovasik, ralph, steved | ||||||
| Target Milestone: | --- | Keywords: | Triaged | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 2.2.49-3.fc13 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 571751 580572 (view as bug list) | Environment: | |||||||
| Last Closed: | 2010-01-05 13:16:02 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 571751, 580572 | ||||||||
| Attachments: |
|
||||||||
|
Description
M. Steinborn
2008-10-21 18:47:53 UTC
Hi, this is quite a big change so it should be accepted by upstream first. I'm going to ask them. This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Did you get any reply from upstream? The third field [of getfacl] contains the discretionary access permissions.
This
standard defines the following symbolic discretionary access
permissions:
r Read access
w Write access
x Execute/search access
- No access by this ACL entry
The discretionary access permissions field shall contain exactly one
each of the following characters in the following order: r, w, and x.
Each of these may be replaced by the "-" character to indicate no
access. An implementation may define additional characters following the
required characters that represent implementation-defined permissions.
Also there is this:
http://acl.bestbits.at/pipermail/acl-devel/2004-September/001743.html
[1]
http://wt.xpilot.org/publications/posix.1e/download/Posix_1003.2c-990310.pdf.gz
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping A fix for this is available in acl 2.2.49: http://download.savannah.gnu.org/releases-noredirect/acl/acl-2.2.49.src.tar.gz Well, the standard situations seem to work now. But once again I managed to construct a situation where the SUID-Bit is lost using setfacl version 2.2.49: -------------- cut here -------------------- root@acer:/tmp/test>ls -l insgesamt 28 -rwsr-xr-x 1 bin root 22984 30. Nov 10:37 passwd -rw-r--r-- 1 root root 89 30. Nov 10:38 passwd.acl root@acer:/tmp/test>cat passwd.acl # file: passwd # owner: root # group: root # flags: s-- user::rwx group::r-x other::r-x root@acer:/tmp/test>/tmp/1/acl-2.2.49/setfacl/setfacl --restore passwd.acl root@acer:/tmp/test>ls -l insgesamt 28 -rwxr-xr-x 1 root root 22984 30. Nov 10:37 passwd -rw-r--r-- 1 root root 89 30. Nov 10:38 passwd.acl root@acer:/tmp/test> -------------- cut here -------------------- PS: Set version to rawhide as this bug applies to every red hat linux (incl. RHEL). So it is not wise to let this bug expire. Works fine here. Something about how you are running that binary from a directory must be breaking something. Please try again after installing the binary properly. jenkins:/home/philips/test # touch passwd jenkins:/home/philips/test # cat > passwd.acl # file: passwd # owner: root # group: root # flags: s-- user::rwx group::r-x other::r-x jenkins:/home/philips/test # ls -la total 20 drwxr-xr-x 2 philips users 4096 2009-12-02 10:57 . drwxr-xr-x 111 philips users 12288 2009-12-02 10:52 .. -rw-r--r-- 1 root root 0 2009-12-02 10:57 passwd -rw-r--r-- 1 root root 88 2009-12-02 10:57 passwd.acl jenkins:/home/philips/test # setfacl --restore passwd.acl jenkins:/home/philips/test # ls -la total 20 drwxr-xr-x 2 philips users 4096 2009-12-02 10:57 . drwxr-xr-x 111 philips users 12288 2009-12-02 10:52 .. -rwsr-xr-x 1 root root 0 2009-12-02 10:57 passwd -rw-r--r-- 1 root root 88 2009-12-02 10:57 passwd.acl I am sorry to tell you, but you have missed an important point: My test starts with a "passwd"-file owned by user "bin" (woith suid flag set), not "root"! After setfacl it is owned by root and should be suid.
Your test also works for me.
BTW: Running the setfacl command twice helps in my test case. This is quite a good workaround.
THe man page states that this sould work:
setfacl attempts to restore the owner and owning group. If the
input contains flags comments (which define the setuid, setgid, and
sticky bits), setfacl sets those three bits accordingly
Note: In my above test, "bin" and "root" are arbitraty, ordinary users could also been used. But you have to run the test as root.
Is this test case usefull? IMHO yes, suppose you want to change some User IDs. You can do it the following way:
1) getfacl -R --absolute-names /home > /tmp/acl.backup.txt
2) Change UIDs in /etc/passwd
3) Corrent owners by
setfacl --restore /tmp/acl.backup.txt
Created attachment 375723 [details]
[PATCH] setfacl: changing owner and when S_ISUID should be set --restore fix
Could you try this patch out. I think it should fix the issue.
Works like a charm for me. BTW: The bug http://savannah.nongnu.org/bugs/?28131 keeps me from updating acl from version 2.2.39 + improved version of my patch from the initial posting of this bug report. @Redhat: What about updating to version 2.2.49 + above patch? With an invalid flags line you can cause a core dump. But this is a new bug. so there is a new bug report on https://savannah.nongnu.org/bugs/index.php?28185 . Created attachment 379082 [details]
setfacl: changing owner and when S_ISUID should be set --restore fix
This patch avoids yet another stat() and does the same thing. This should be the final fix for this.
Just as a reminder: The patch attached to this bug report (which is by the way from upstream) is missing in the latest koji builds. I still can't see the patch in the upstream git. Brandon, is there any reason to hold on with applying the patch? (In reply to comment #15) > I still can't see the patch in the upstream git. > > Brandon, is there any reason to hold on with applying the patch? Forgot to push. It should be there now. The patch should be fine. Thank you, Brandon! Built as acl-2.2.49-3.fc13. Will this fix also find its way to RHEL ? Currently RHEL5.4 also suffers from that bug (as reported here: http://trac.mondorescue.org/ticket/399) Is it too late for RHEL5.5 ? (In reply to comment #18) > Is it too late for RHEL5.5 ? Yep, it's too late... but feel free to clone that bugzilla against RHEL-5 to increase chances to get this fixed in future RHEL-5 acl update. |