Description of problem: Restore of tar archive blocked Version-Release number of selected component (if applicable): selinux-policy-targeted-3.6.12-53.fc11.noarch How reproducible: Every time Steps to Reproduce: 1.Create tar archive of home directories on Fedora 10 with option --xattrs 2.Restore tar on Fedora 11 system 3. Actual results: The restore fails with an error. Expected results: Additional info: time->Tue Jul 7 19:43:25 2009 type=SYSCALL msg=audit(1247021005.307:937): arch=c000003e syscall=188 success=no exit=-22 a0=170b8d0 a1=3f20c15b79 a2=18a0c20 a3=23 items=0 ppid=16290 pid=16644 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=99 comm="tar" exe="/bin/tar" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1247021005.307:937): avc: denied { mac_admin } for pid=16644 comm="tar" capability=33 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=capability2
The problem you are having is some context in your F10 system no longer exists on your F11 system, and the system is refusing to allow you to put it on. Basically the F11 kernel does not understand the context so it is not allowing it.
Then from your information I would say we are not reliably able to use tar or any other archive utility if we save the security attributes and expect to be able to do a restore. You can only expect it to work if your restoring to the same version of the operating system and possibly only if there have been no policy updates.
Yes, but was this a failure of the tar or did it install the file with a default context? I would liken this somewhat to tarring up a file on my machine with user dwalsh and then installing it on your machine where you may or may not have my UID defined. I would think tar would work the same way.
We do not know if the files were installed. There were too many to easily check. But since the tar said it failed with an error we did not trust the restore and modified the policy. Then it restored the tar much like a non existent user without any indication of error. We then found that not all the files were labeled right and had to relabel the users directories.
What files was the tar complaining about for labeling?
These for sure, may have been more: ausearch -m avc | less type=AVC msg=audit(1247048404.800:1532): avc: denied { getattr } for pid=22925 comm="updatedb" path="/export/home/dhighley/.fonts" dev=dm-2 ino=557938 scontext=system_u:system_r:locate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir ---- time->Wed Jul 8 03:20:05 2009 type=SYSCALL msg=audit(1247048405.440:1533): arch=c000003e syscall=6 success=no exit=-13 a0=25cac09 a1=7fffc163f120 a2=7fffc163f120 a3=65686361632f636c items=0 ppid=22919 pid=22925 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=117 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1247048405.440:1533): avc: denied { getattr } for pid=22925 comm="updatedb" path="/export/home/dhighley/.vmware" dev=dm-2 ino=397240 scontext=system_u:system_r:locate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
So you put them down in permissive mode? could you look at the labels on them getfattr -n security.selinux /export/home/dhighley/.vmware /export/home/dhighley/.fonts
Remember we have done a restorecon -Rv of each home directory. So we may not be able to see what the issue was. getfattr -n security.selinux export/home/dhighley/.vmware # file: export/home/dhighley/.vmware security.selinux="unconfined_u:object_r:vmware_file_t:s0\000" getfattr -n security.selinux export/home/dhighley/.fonts # file: export/home/dhighley/.fonts security.selinux="unconfined_u:object_r:user_fonts_t:s0\000"