# SElinux chcon command not updating ctime

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

( 2014-01-14 14:57:38 -0500 )edit

Sort by » oldest newest most voted

There is an interesting reading about pros/cons of backing up selinux context http://danwalsh.livejournal.com/48936.html. I'm not sure this helps, but I've made some experiments with tar/rsync (see http://www.cyberciti.biz/faq/linux-tar-rsync-preserving-acls-selinux-contexts/) 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 -
cd
# 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 http://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html
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 http://docs.fedoraproject.org/en-US/Fedora/13/html/SELinux_FAQ/index.html#id3037344

more