Description of problem: After restoring a root partition backup with tar --xattrs symlinks are having a wrong selinux-context. Version-Release number of selected component (if applicable): tar-1.22-4.fc11.x86_64 How reproducible: everytime Steps to Reproduce: tar cpf /tmp/test.tar --xattrs /lib64/libblkid* tar xpf /tmp/test.tar --xattrs ls -Z /lib64/libblkid* ls -Z lib64 Actual results: [root@krabat ~]# ls -Z /lib64/libblkid* lrwxrwxrwx. root root system_u:object_r:lib_t:s0 /lib64/libblkid.so.1 -> libblkid.so.1.0 -rwxr-xr-x. root root system_u:object_r:lib_t:s0 /lib64/libblkid.so.1.0 [root@krabat ~]# ls -Z lib64 lrwxrwxrwx. root root unconfined_u:object_r:admin_home_t:s0 libblkid.so.1 -> libblkid.so.1.0 -rwxr-xr-x. root root system_u:object_r:lib_t:s0 libblkid.so.1.0 Expected results: Same selinux-context for restored symlinks.
star restores the symlinks from an archiv created with tar correctly (also it doesn't like some other things in such an archiv), so I assume the selinux-contexts for symlinks are stored correctly by tar and it just don't restores them.
Thanks for report. Confirmed. Really restored correctly by star? Strange, as it seems the selinux-context is not stored (restoring for symlinks seems to be ok, but storing of xattrs/selinux context is not done for the symlinks) .
It might be that star just gives the symlinks the context of their target, haven't checked that.
BTW: It would be nice, if star could be included in the live-cds. So users could use tar or star to (build or) restore backups. At least the KDE-Live-CD does not have star installed. A good time could be when updated Live-CDs are build with a fixed tar. ;)
(In reply to comment #1) > star restores the symlinks from an archiv created with tar correctly (also it > doesn't like some other things in such an archiv), so I assume the > selinux-contexts for symlinks are stored correctly by tar and it just don't > restores them. Are you sure? I am observing exactly opposite behavior: $ tar c /lib64/libblkid.so* --xattr > /tmp/t.tar $ star xf /tmp/t.tar && /usr/bin/find lib64/* -printf "%p\t%Z\n" star: Unknown extended header keyword 'RHT.security.selinux' ignored at 4. star: 6 blocks + 0 bytes (total of 61440 bytes = 60.00k). lib64/libblkid.so.1 unconfined_u:object_r:user_tmp_t:s0 lib64/libblkid.so.1.0 unconfined_u:object_r:user_tmp_t:s0 $ star c artype=exustar -xattr /lib64/libblkid.so* > /tmp/t.tar $ tar xf /tmp/t.tar && /usr/bin/find lib64/* -printf "%p\t%Z\n" tar: Removing leading `/' from member names lib64/libblkid.so.1 system_u:object_r:lib_t:s0 lib64/libblkid.so.1.0 system_u:object_r:lib_t:s0
Hmm, you are right. Maybe star solved my problem because the created symlinks got the rights of the target they are pointing to, so autorelabel corrected them. Using tar I had different rights and it might be, that this wasn't corrected by an autolabel. But I can't remember. I only remember that I had major problems restoring an Fedora 11 from an archiv created with tar --xattr (because that symlink libblkid.so.1) and restoring it with star solved that. Which doesn't change the topic of this bug, that tar restores symlinks wrong ;)
Maybe I've just forgot to set enforcing=0 in addition to autorelabel after restoring the archiv created with tar and that enforcing=0 was not needed after restoring with star. I didn't know much about selinux before and I'm still learning.
Created attachment 370193 [details] store SELinux context for symlinks
I've just built it for rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=141887 Let me know if you need a F-11 scratch build for testing.
Created attachment 370315 [details] follow-up for xattrs
Scratch build for F-11 including both patches: http://koji.fedoraproject.org/koji/taskinfo?taskID=1816233
I've just tested the new tar with the directory (see above) where the symlink has different contexts as the target. The result is a symlink and target which have both the same contexts. Maybe this should be written down under BUGS in the manpage. Someone might have a reason to use different contexts for a symlink and his target and he should notified that this is not archived using tar.
Oh, hmm, it's the other way around. It seems the target will get the right of the symlink. Don't know if this will work. This is what I've stored using the new tar: root@krabat ~]# ls -Z lib64/ lrwxrwxrwx. root root unconfined_u:object_r:admin_home_t:s0 libblkid.so.1 -> libblkid.so.1.0 -rwxr-xr-x. root root system_u:object_r:lib_t:s0 libblkid.so.1.0 And this is what I have had after restoring: [root@krabat t2]# ls -Z lib64/ lrwxrwxrwx. root root unconfined_u:object_r:admin_home_t:s0 libblkid.so.1 -> libblkid.so.1.0 -rwxr-xr-x. root root unconfined_u:object_r:admin_home_t:s0 libblkid.so.1.0
Thinking slowly, but thinking. ;) What happens if I'm storing two symlinks to the same target all with different contexts? I think the only solution (if only one context is actually stored in the archiv) is to give the symlinks the context of the target.
I've tried a symlink to regular file and a dangling symlink, both seemed to work. Please write some steps to reproduce - how exactly did you run tar?
I've used the directory lib64 (with different contexts) I've got with the old tar (see above). Than I've done the following: tar cpf /tmp/test2.tar lib64 mkdir t2 cd t2 tar xpf /tmp/test2.tar --xattrs
[root@krabat ~]# rpm -qa | grep tar-1 libtar-1.2.11-11.fc10.x86_64 tar-1.22-4.1.fc11.x86_64 star-1.5-4.fc11.x86_64
uups, seen my failure, I've forgot --xattrs while packing. Sorry.
Thanks for fixing the bug, and again, sorry for the last false reports.
Np. Thanks for testing it! However symlink vs. SELinux handling still doesn't look perfect while extracting. tar fails to restore SELinux context for symlinks starting with '/' unless it is invoked with --absolute-names. I think it will need yet another iteration...
Created attachment 372321 [details] keep SELinux context and xattrs for delayed symlink extraction
Scratch build for F-11 including all three patches: http://koji.fedoraproject.org/koji/taskinfo?taskID=1817916 Any feedback welcome!
tar-1.22-5.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/tar-1.22-5.fc11
tar-1.22-5.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update tar'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/tar-1.22-5.fc11
tar-1.22-5.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.