Ask Your Question

SElinux chcon command not updating ctime

asked 2014-01-06 13:29:19 -0500

derekp7 gravatar image

updated 2014-01-06 13:30:28 -0500

It appears that whenever a file's SElinux security context is updated (with chcon), the file's ctime does NOT get updated (unlike when you update ACLs, permissions, etc). The problem is, that most backup software will look at the file's ctime and/or mtime when making incremental backups. So the question is, is there somewhere else I should be looking at to determine if a file's security context has been updated since the last backup? For the time being, I've decided to grab and store the current security context of each file, whenever I scan for modified files. But it would be nice to be able to use, for example "find -cnewer ..." and have it return these files too.

BTW, any answer is acceptable, even if it includes modifying my backup software.

edit retag flag offensive close merge delete


Not sure I get the full scope of the problem statement, but here is my two cents. Not sure SElinux could, or even should be able to change the ctime of a file. For example, you cannot do that yourself for files you own using the touch(1) command. As far as I know only can be achieved by using something liked debugfs(8) with the filesystem offline. But since SElinux is in the kernel, perhaps this is doable, but again... does SELinux really change anything about the file data, inode, or is it altering something else?

parasense gravatar imageparasense ( 2014-01-14 14:57:38 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2014-01-14 07:22:29 -0500

marcindulak gravatar image

updated 2014-01-14 08:31:26 -0500

There is an interesting reading about pros/cons of backing up selinux context I'm not sure this helps, but I've made some experiments with tar/rsync (see and they seem to work "more or less" for incremental backups with selinux enforcing. I have noticed that the context is not handled correctly for making backups of some directories, depending if run as root or not (directories like /tmp, but who wants to backup /tmp?). This, and the fact that complete tutorials how to handle backups with selinux are hard to find, suggests that the problem is tricky.

Example for Fedora 19, for reference, in case someone wants to experiment more:

su -
# tar wont get the correct selinux context if "cd /tmp" instead, run as root or not!
# rsync will get the correct context if "cd /tmp" and run as root!
mkdir d1
touch d1/f{1,2}

ls -lZ d1
# -rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 f1
# -rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 f2

# initial backup with tar
# see
tar --listed-incremental=/tmp/d1.snar --selinux --acls --xattrs -cvf /tmp/d1.00.tar d1
# tar: d1: Directory is new
# d1/
# d1/f1
# d1/f2
cp -p /tmp/d1.snar /tmp/d1.00.snar

# initial backup with rsync
rsync -av -A -X d1 /tmp/rsyncbackup
# ...
# created directory /tmp/rsyncbackup
# d1/
# d1/f1
# d1/f2
# ...

# now change a context of a file
chcon system_u:object_r:rpm_tmp_t:s0 d1/f2

tar --listed-incremental=/tmp/d1.snar --selinux --acls --xattrs -cvf /tmp/d1.01.tar d1
# d1/
# d1/f2
cp -p /tmp/d1.snar /tmp/d1.01.snar

rsync -avv -A -X d1 /tmp/rsyncbackup
# ...
# d1/f1 is uptodate
# d1/f2 is uptodate  # rscync reports uptodate, but copies the file anyway
# ...

mkdir /tmp/tarbackup&& cd /tmp/tarbackup
tar --listed-incremental=/dev/null --selinux --acls --xattrs -xvf /tmp/d1.00.tar
tar --listed-incremental=/dev/null --selinux --acls --xattrs -xvf /tmp/d1.01.tar

ls -lZ /tmp/{rsync,tar}backup/d1
# -rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 f1
# -rw-r--r--. root root system_u:object_r:rpm_tmp_t:s0   f2
# ...

Bacula is also supposed to support selinux

edit flag offensive delete link more

Question Tools


Asked: 2014-01-06 13:29:19 -0500

Seen: 591 times

Last updated: Jan 14 '14