's' file attribute lost (example: /usr/bin/sudo) if -z flag used at backup time

[kritzenthaler]

Hello,

I have found quite an annoying defect which can impact the proper functionning of a server after restore.

The issue was observed on RHEL5.4. The issue is observed only with the -z flag.

Command-line to make the backup was:

mondoarchive -OVi -N -d /home/backup -E /home/backup -s 4480m -z

Before backup :
===============

[root@lagrave /]# ll /usr/bin/sudo

---s--x--x 2 root root 140804 Apr 14 2009 /usr/bin/sudo

After restore (if -z flag used for backup):
===============

[root]# ll /usr/bin/sudo

---x--x--x 2 root root 140804 Apr 14 2009 /usr/bin/sudo

After restore (if -z flag was not used for backup):
===============

[root]# ll /usr/bin/sudo

---s--x--x 2 root root 140804 Apr 14 2009 /usr/bin/sudo


What we observe is that we loose the 's' attribute if the -z flag is used at backup time.

It has quite an impact since we can not use anylonger /usr/bin/sudo and possibly other commands after restore :

[ocadmin]$ sudo
sudo: must be setuid root

The issue seems to be lying in the fact that 'acl_list*' files are used to backup attributes only with the -z flag. Those 'acl_list*' files do not seem to backup properly the 's' attribute.

As an example for /usr/bin/sudo, we see that the associated acl_list file contains 'x' attribute instead of 's': ====================
# file: usr/bin/sudo # owner: root # group: root user::--x group::--x other::--x ====================

[kritzenthaler]

I found out that the culprit is the command 'getfacl' which does not return the 's' attribute by default.
Since the getfacl command is only used altogether with the -z flag, it does make sense to observe the issue only when the -z flag is activated:

[root]# getfacl /usr/bin/sudo
getfacl: Removing leading '/' from absolute path names
# file: usr/bin/sudo
# owner: root
# group: root
user::--x
group::--x
other::--x

Whereas 'ls -l' shows the 's' attribute correctly:
[root]# ll /usr/bin/sudo
---s--x--x 2 root root 140804 Apr 14 2009 /usr/bin/sudo

[kritzenthaler]

A possible solution (to be investigated) would be to use the --skip-base flag of getfacl command to avoid saving and over-riding later on the base attributes.

With --skip-base, it seems that we can save only extended attributes, thus not impacting the base ones.

[kritzenthaler]

Apparently, this 'getfacl' issue has been known for quite some time:

​http://acl.bestbits.at/pipermail/acl-devel/2004-September/001743.html[[BR]] ​https://bugzilla.redhat.com/show_bug.cgi?id=467936[[BR]]

Also, my RHEL5.4 contains acl-2.2.39-3.el5.i386 and the issue is fixed in 2.2.49 only.

[dluijkx]

We are also having this issue on RHEL 5.5 and version 2.2.9.2 (loss of the "s" attribute). It was noticed initially when trying to do "su -" and noticing the suid bit not being set on /bin/su We are also using the -z when calling mondoarchive:

/usr/sbin/mondoarchive -NOViz -9 -d $mondoexpdir -s 4478m -E '/r01 /r02 /r03 /tmp' -p $HOST_NAME.$DAYSTAMP

I will revert to 2.2.8.1 which works fine for us with the above flags.

======under /bin==================================== ...all the files under /bin lost the "s" attribute, and some files under /usr lost this.

source system that created the mondo archive: # ------------ EOS

cd /bin

[root@eos bin]# find . -perm 4755 -ls

180282 32 -rwsr-xr-x 1 root root 32736 Jul 2 2009 ./ping6

180311 40 -rwsr-xr-x 1 root root 37312 Jul 2 2009 ./ping

180317 44 -rwsr-xr-x 1 root root 41224 Jan 19 11:51 ./umount

180286 28 -rwsr-xr-x 1 root root 28336 Feb 24 05:34 ./su

180272 64 -rwsr-xr-x 1 root root 61424 Jan 19 11:51 ./mount

---

cd /bin

[root@bia bin]# find . -perm 4755 -ls

[root@bia bin]#

[root@bia bin]# ls -l |egrep "ping|umount|su"

-rwxr-xr-x 1 root root 37312 Jul 2 2009 ping

-rwxr-xr-x 1 root root 32736 Jul 2 2009 ping6

-rwxr-xr-x 1 root root 28336 Feb 24 05:34 su

-rwxr-xr-x 1 root root 41224 Jan 19 11:51 umount

====under /usr/bin===============================

source system (created mondo archive):

cd /usr

[root@eos usr]# find . -perm 4755 -ls

1441853 176 -rwsr-xr-x 1 root root 176072 Feb 26 08:42 ./libexec/openssh/ssh-keysign

786444 64 -rwsr-xr-x 1 root root 61420 Jul 18 2008./lib/nspluginwrapper/plugin-config

1392650 200 -rwsr-xr-x 1 root root 199511 Jan 12 16:36 ./kerbero/bin/ksu

1638761 12 -rwsr-xr-x 1 root root 8848 Sep 3 2009 ./sbin/usernetctl

1638425 12 -rwsr-xr-x 1 root root 8544 Aug 22 2006 ./sbin/ccreds_validate

1638495 12 -rwsr-xr-x 1 root root 8672 Jul 2 2009 ./sbin/userisdnctl

279157 64 -rwsr-xr-x 1 root root 60432 Jul 18 2008 ./lib64/nspluginwrapper/plugin-config

409948 28 -rwsr-xr-x 1 root root 27768 Jul 17 2006 ./bin/passwd

411438 12 -rwsr-xr-x 1 root root 11328 Jul 2 2009 ./bin/rsh

410804 20 -rwsr-xr-x 1 root root 20384 Jul 2 2009 ./bin/rcp

1233423 56 -rwsr-xr-x 1 root root 49872 Aug 23 2006 ./bin/at

409807 56 -rwsr-xr-x 1 root root 51576 Oct 31 2008 ./bin/gpasswd

409835 28 -rwsr-xr-x 1 root root 28552 Oct 31 2008 ./bin/newgrp

409732 16 -rwsr-xr-x 1 root root 15552 Jul 2 2009 ./bin/rlogin

410004 56 -rwsr-xr-x 1 root root 50680 Oct 31 2008 ./bin/chage

====destination (restored) system (has lost "s" on some files):

cd /usr

[root@bia usr]# find . -perm 4755 -ls

1343600 60 -rwsr-xr-x 1 root root 55792 Feb 15 15:26 ./lib/nspluginwrapper/plugin-config

805500 60 -rwsr-xr-x 1 root root 57152 Feb 15 15:31 ./lib64/nspluginwrapper/plugin-config

1147666 48 -rwsr-xr-x 1 root root 47856 Feb 11 18:08 ./bin/gpasswd

1147374 48 -rwsr-xr-x 1 root root 47024 Feb 11 18:08 ./bin/chage

1147688 28 -rwsr-xr-x 1 root root 25160 Feb 11 18:08 ./bin/newgrp

1147336 56 -rwsr-xr-x 1 root root 49392 Feb 11 02:14 ./bin/at

346932 176 -rwsr-xr-x 1 root root 176072 Feb 11 16:08 ./libexec/openssh /ssh-keysign

295033 12 -rwsr-xr-x 1 root root 8848 Mar 3 20:33 ./sbin/usernetctl

[Bruno Cornec]

Reported on RHEL5 tree at ​https://bugzilla.redhat.com/show_bug.cgi?id=580572

[Bruno Cornec]

I got feedback from Red Hat that it should be fixed for RHEL 5.7.

Closing here, as this is much more RHEL related and in their hands now.

[Bruno Cornec]

Replying to bruno:

I got feedback from Red Hat that it should be fixed for RHEL 5.7.

Well not really. The new feedback is that it will be later on :-(

[Bruno Cornec]

Now fixed by Red Hat. Please update your distros !! Cf: ​http://rhn.redhat.com/errata/RHBA-2012-0242.html