+++ This bug was initially created as a clone of Bug #467936 +++ Note: This bug is also present in Fedora 8 and 9, RHEL 5.2. Suppose, you want to create a backup using GNU tar and getfacl (the former for the contents of the files, the latter for the ACLs). So far that is working quite good. Needing the backup, you'll restore it with "tar -xnpf ..." and restore the ACLs with "setfacl --restore ..." and what a pain, all SUID-Bits, GUID-Bits etc. are deleted. The fastest test is the command line getfacl -R . | setfacl --restore -. Warning:The whole directory tree is processed recursivly! A german discussion concerning this bug can be read here (http://tinyurl.com/442evz). The link is pointing to google groups. That discussion lead to ideas, which I implemented by the following patches: (Note: You can find the patches on http://www.markus-steinborn.de/acl/index.enu.htm ) To the user, the changes look as follows: msteinbo@aasiaat:/privat/msteinbo/tmp>touch test.sh; chmod 4725 test.sh msteinbo@aasiaat:/privat/msteinbo/tmp>ls -l total 0 -rws-w-r-x 1 msteinbo infoabc 0 2008-02-15 12:48 test.sh msteinbo@aasiaat:/privat/msteinbo/tmp>getfacl test.sh | tee test.acls # file: test.sh # owner: msteinbo # group: infoabc # mode: 04725 user::rwx group::-w- other::r-x [Notice the new comment line with the octal mode of the file. Using a new comment line should ensure maximum compatibility to existing software.] msteinbo@aasiaat:/privat/msteinbo/tmp>chmod 0000 test.sh ; ls -l test.sh ---------- 1 msteinbo infoabc 0 2008-02-15 12:48 test.sh msteinbo@aasiaat:/privat/msteinbo/tmp>setfacl --restore test.acls ; ls -l test.sh -rws-w-r-x 1 msteinbo infoabc 0 2008-02-15 12:48 test.sh [The Mode-Comment triggers a "chmod(2)", which is executed last and therefore it's effects are not overwritten. Furthermore, the patch introduces the following new options: getfacl: --with-mode include mode in output --without-mode do not include mode in output - also available via environment variable ACL_OUTPUT_WO_MODE setfacl: --keep-smodes for --restore: keep suid/sgid/sticky-bits --no-keep-smodes for --restore: do not keep suid/sgid/sticky-bits The option "--keep-smodes" enables the user to restore backups that are created as described above on an unpatched system without any errors. --- Additional comment from jmoskovc on 2008-10-31 09:22:58 EDT --- Hi, this is quite a big change so it should be accepted by upstream first. I'm going to ask them. --- Additional comment from fedora-triage-list on 2008-11-25 23:05:51 EST --- 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 --- Additional comment from gnugv_maintainer on 2009-04-05 12:43:38 EDT --- Did you get any reply from upstream? --- Additional comment from brandon on 2009-05-08 19:00:33 EDT --- 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 --- Additional comment from fedora-triage-list on 2009-11-18 03:37:09 EST --- 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 --- Additional comment from brandon on 2009-11-29 15:12:04 EST --- 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 --- Additional comment from gnugv_maintainer on 2009-11-30 05:21:32 EST --- 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. --- Additional comment from brandon on 2009-12-02 13:59:41 EST --- 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 --- Additional comment from gnugv_maintainer on 2009-12-03 02:28:43 EST --- 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 --- Additional comment from brandon on 2009-12-03 05:00:21 EST --- Created an attachment (id=375723) [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. --- Additional comment from gnugv_maintainer on 2009-12-05 13:31:47 EST --- 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? --- Additional comment from gnugv_maintainer on 2009-12-05 15:13:00 EST --- 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 . --- Additional comment from brandon on 2009-12-17 15:19:39 EST --- Created an attachment (id=379082) 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. --- Additional comment from gnugv_maintainer on 2009-12-27 04:40:48 EST --- 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. --- Additional comment from kdudka on 2009-12-27 05:36:41 EST --- I still can't see the patch in the upstream git. Brandon, is there any reason to hold on with applying the patch? --- Additional comment from brandon on 2009-12-31 22:18:03 EST --- (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. --- Additional comment from kdudka on 2010-01-05 08:16:02 EST --- Thank you, Brandon! Built as acl-2.2.49-3.fc13. --- Additional comment from bruno.cornec on 2010-03-06 20:11:43 EST --- 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 ? --- Additional comment from ovasik on 2010-03-09 03:11:49 EST --- (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.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Do you mean that it will never been fixed in RHEL 5.x ? Do you mean I also need to clone it for RHEL 6 ?
No, it was just automated message informing you that the fix is not planned for upcoming RHEL-5.6 minor update. It still could be solved later in RHEL-5.7+ if the acl update will get approved by PM. If you want to increase chances of the acl package update, contact Red Hat product support - as Bugzilla is just bug tracking system for RHEL. You don't have to clone it for RHEL-6...
Created attachment 473538 [details] backport of related upstream patches http://git.savannah.gnu.org/cgit/acl.git/commit/?id=45833cc http://git.savannah.gnu.org/cgit/acl.git/commit/?id=8c635f8 http://git.savannah.gnu.org/cgit/acl.git/commit/?id=1623002
This bug still exists in RHEL 6.2 - specifically, if I do 'getfacl file1 | setfacl --set-file=- file2', the setuid, setgid and sticky bits are ignored. This bug has been NOT included in RHEL 5/6 fixes for over a year - please fix it for the next release.
(In reply to comment #18) > This bug still exists in RHEL 6.2 - specifically, if I do 'getfacl file1 | > setfacl --set-file=- file2', the setuid, setgid and sticky bits are ignored. This bug was about setfacl --restore. Are you referring to a particular upstream fix?
No, I was pointing out that this is an open security-related bug that has been pushed back 3 RHEL5 releases, and that it also affects RHEL6. Also, while I suppose it's possible that the internal mechanisms are actually different, setfacl --restore and setfacl --set-file are effectively the same thing when a single file is involved, and neither one properly restores the setXid and sticky bits. Also, since upstream patches were posted to this bug over a year ago, I don't understand why this has still not been addressed.
I have tried your example. I get the same results on RHEL-6.2 as I get for the upstream acl. If the behavior is wrong, then it is an upstream bug and it needs to be fixed upstream.
josh: If you are trying to report the new issue, please open new bugzilla. In addition, if you have security concerns about this, feel free to ask secalert about it... this bugzilla is not marked security and was not reported by customer support. Priority of the RHEL updates is driven by customer requests, as the update capacity is of course limited. If you want to increase the priority of some fix, please escalate it via product support. Bugzilla (in the case of RHEL) is just tracking tool, not support tool.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0242.html