Hi folks,
normally I have not so much to do with SElinux but I expected to get in touch sooner or later :-)
I migrated a backup-system from El5 to EL6 and the rsync backup process is complaining about selinux attr's now.
client <-> server (fetches via rsync -aHAX)
client# sestatus SELinux status: disabled
server# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 24 Policy from config file: targeted
for example, no label for this file on client side:
client# ls -laZ /usr/share/zoneinfo/Africa/Bissau -rw-r--r-- root root /usr/share/zoneinfo/Africa/Bissau
but on server side:
rsync: rsync_xal_clear: lremovexattr("usr/share/zoneinfo/Africa/.Bissau.WaE4wj","security.selinux") failed: Permission denied (13)
and
server# ls -laZ /BACKUP/usr/share/zoneinfo/Africa/Bissau -rw-r--r--. root root unconfined_u:object_r:locale_t:s0 usr/share/zoneinfo/Africa/Bissau
the local (server) destination is mounted like:
server# cat /proc/mounts |grep BACKUP /dev/sdc1 /BACKUP ext3 rw,seclabel,nosuid,nodev,noatime,nodiratime,errors=continue,acl,barrier=1,data=ordered 0 0
this partition comes from the former system (EL5 productively used without labeling it and with SElinux disabled).
I started to enable SElinux (permissive) on new systems and therefore disabling SElinux like it was done before on the former system is not an option.
Any suggestions to avoid the default labeling "unconfined_u:object_r:locale_t:s0"?
-- Thanks, LF
On 10/24/2016 09:53 AM, Leon Fauster wrote:
Any suggestions to avoid the default labeling "unconfined_u:object_r:locale_t:s0"?
Not off the top of my head. I think you need to either a) not try to preserve the labels or b) run the backup as a user which can manage labels. What is the rsync command you are currently using, and what user does rsync run as on the backup server?
Am 24.10.2016 um 23:44 schrieb Gordon Messmer gordon.messmer@gmail.com:
On 10/24/2016 09:53 AM, Leon Fauster wrote:
Any suggestions to avoid the default labeling "unconfined_u:object_r:locale_t:s0"?
Not off the top of my head. I think you need to either a) not try to preserve the labels or b) run the backup as a user which can manage labels. What is the rsync command you are currently using, and what user does rsync run as on the backup server?
Plain rsync -aHAX with some excludes and executed as root on the backup system.
Doing so I get: <snip> rsync: rsync_xal_clear: lremovexattr("lib/modules/2.6.18-412.el5/modules.alias","security.selinux") failed: Permission denied (13) rsync: rsync_xal_clear: lremovexattr("lib/modules/2.6.18-412.el5/modules.ccwmap","security.selinux") failed: Permission denied (13) rsync: rsync_xal_clear: lremovexattr("lib/modules/2.6.18-412.el5/modules.dep","security.selinux") failed: Permission denied (13) rsync: rsync_xal_clear: lremovexattr("lib/modules/2.6.18-412.el5/modules.ieee1394map","security.selinux") failed: Permission denied (13) rsync: rsync_xal_clear: lremovexattr("lib/modules/2.6.18-412.el5/modules.inputmap","security.selinux") failed: Permission denied (13) rsync: rsync_xal_clear: lremovexattr("lib/modules/2.6.18-412.el5/modules.isapnpmap","security.selinux") failed: Permission denied (13) rsync: rsync_xal_clear: lremovexattr("lib/modules/2.6.18-412.el5/modules.ofmap","security.selinux") failed: Permission denied (13) rsync: rsync_xal_clear: lremovexattr("lib/modules/2.6.18-412.el5/modules.pcimap","security.selinux") failed: Permission denied (13) <snip>
The thing is, that files from the source system that doesn't have a label get a new one on the destination system. Here is some kind of inheritance in place.
client# ls -laZ /lib/modules/2.6.18-412.el5/modules.* -rw-r--r-- root root /lib/modules/2.6.18-412.el5/modules.alias -rw-r--r-- root root /lib/modules/2.6.18-412.el5/modules.ccwmap -rw-r--r-- root root /lib/modules/2.6.18-412.el5/modules.dep -rw-r--r-- root root /lib/modules/2.6.18-412.el5/modules.ieee1394map -rw-r--r-- root root /lib/modules/2.6.18-412.el5/modules.inputmap -rw-r--r-- root root /lib/modules/2.6.18-412.el5/modules.isapnpmap -rw-r--r-- root root /lib/modules/2.6.18-412.el5/modules.ofmap -rw-r--r-- root root /lib/modules/2.6.18-412.el5/modules.pcimap -rw-r--r-- root root /lib/modules/2.6.18-412.el5/modules.seriomap -rw-r--r-- root root /lib/modules/2.6.18-412.el5/modules.symbols -rw-r--r-- root root /lib/modules/2.6.18-412.el5/modules.usbmap
backupserver# ls -laZ daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.* -rw-r--r--. root root unconfined_u:object_r:modules_object_t:s0 daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.alias -rw-r--r--. root root unconfined_u:object_r:modules_object_t:s0 daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.ccwmap -rw-r--r--. root root unconfined_u:object_r:modules_object_t:s0 daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.dep -rw-r--r--. root root unconfined_u:object_r:modules_object_t:s0 daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.ieee1394map -rw-r--r--. root root unconfined_u:object_r:modules_object_t:s0 daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.inputmap -rw-r--r--. root root unconfined_u:object_r:modules_object_t:s0 daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.isapnpmap -rw-r--r--. root root unconfined_u:object_r:modules_object_t:s0 daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.ofmap -rw-r--r--. root root unconfined_u:object_r:modules_object_t:s0 daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.pcimap -rw-r--r--. root root unconfined_u:object_r:modules_object_t:s0 daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.seriomap -rw-r--r--. root root unconfined_u:object_r:modules_object_t:s0 daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.symbols -rw-r--r--. root root unconfined_u:object_r:modules_object_t:s0 daily.0/ee-sl1/lib/modules/2.6.18-412.el5/modules.usbmap
Using rsync -aHA (without X) circumvent the output but its still unclear what exactly triggers the above output. The next weekend seems to be reserved for a SElinux dive thought ...
-- LF
On 10/24/2016 04:43 PM, Leon Fauster wrote:
Using rsync -aHA (without X) circumvent the output but its still unclear what exactly triggers the above output.
The '-X' flag attempts to make attributes match on the source and destination files. Since the source files have no SELinux attribute, rsync will try to remove it from the destination, where an attribute has been inherited.
I'm not entirely certain why a file couldn't have no SELinux label, but since you don't have any extended attributes to preserve, the simple solution would be to stop telling rsync to preserve extended attributes.
-
Gordon Messmer -
Leon Fauster