Opened 10 years ago

Closed 9 years ago

Last modified 8 years ago

#399 closed defect (fixed)

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

Reported by: kritzenthaler Owned by: bruno
Priority: high Milestone: 2.2.9.5
Component: mondo Version: 2.2.9.2
Severity: major Keywords:
Cc:

Description

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 ====================

Change History (10)

comment:1 Changed 10 years ago by 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

comment:2 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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

comment:5 Changed 10 years ago by bruno

  • Milestone changed from 2.2.9.3 to 2.2.9.4

comment:7 Changed 9 years ago by bruno

  • Milestone changed from 2.2.9.4 to 2.2.9.5

comment:8 follow-up: Changed 9 years ago by bruno

  • Resolution set to fixed
  • Status changed from new to closed

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.

comment:9 in reply to: ↑ 8 Changed 8 years ago by bruno

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 :-(

comment:10 Changed 8 years ago by bruno

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

Note: See TracTickets for help on using tickets.