Bug 525992

Summary: tar fails to dump/restore SELinux ctx and xattrs for symlinks
Product: [Fedora] Fedora Reporter: Alexander Holler <holler>
Component: tarAssignee: Kamil Dudka <kdudka>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: kdudka, ovasik
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: tar-1.22-5.fc11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-27 01:00:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
store SELinux context for symlinks
none
follow-up for xattrs
ovasik: review+
keep SELinux context and xattrs for delayed symlink extraction ovasik: review+

Description Alexander Holler 2009-09-28 05:54:56 UTC
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.

Comment 1 Alexander Holler 2009-09-28 08:56:49 UTC
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.

Comment 2 Ondrej Vasik 2009-09-28 12:17:53 UTC
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) .

Comment 3 Alexander Holler 2009-09-28 13:45:02 UTC
It might be that star just gives the symlinks the context of their target, haven't checked that.

Comment 4 Alexander Holler 2009-09-28 17:53:04 UTC
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. ;)

Comment 5 Kamil Dudka 2009-11-18 13:05:00 UTC
(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

Comment 6 Alexander Holler 2009-11-18 16:28:07 UTC
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 ;)

Comment 7 Alexander Holler 2009-11-18 16:36:18 UTC
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.

Comment 8 Kamil Dudka 2009-11-18 20:36:49 UTC
Created attachment 370193 [details]
store SELinux context for symlinks

Comment 9 Kamil Dudka 2009-11-18 20:48:09 UTC
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.

Comment 10 Kamil Dudka 2009-11-19 11:35:30 UTC
Created attachment 370315 [details]
follow-up for xattrs

Comment 11 Kamil Dudka 2009-11-19 11:55:50 UTC
Scratch build for F-11 including both patches:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1816233

Comment 12 Alexander Holler 2009-11-19 13:54:45 UTC
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.

Comment 13 Alexander Holler 2009-11-19 14:02:54 UTC
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

Comment 14 Alexander Holler 2009-11-19 14:12:06 UTC
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.

Comment 15 Kamil Dudka 2009-11-19 14:21:01 UTC
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?

Comment 16 Alexander Holler 2009-11-19 14:30:08 UTC
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

Comment 17 Alexander Holler 2009-11-19 14:32:03 UTC
[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

Comment 18 Alexander Holler 2009-11-19 14:39:57 UTC
uups, seen my failure, I've forgot --xattrs while packing. Sorry.

Comment 19 Alexander Holler 2009-11-19 14:50:31 UTC
Thanks for fixing the bug, and again, sorry for the last false reports.

Comment 20 Kamil Dudka 2009-11-19 17:55:10 UTC
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...

Comment 21 Kamil Dudka 2009-11-19 19:28:29 UTC
Created attachment 372321 [details]
keep SELinux context and xattrs for delayed symlink extraction

Comment 22 Kamil Dudka 2009-11-19 19:44:23 UTC
Scratch build for F-11 including all three patches:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1817916

Any feedback welcome!

Comment 26 Fedora Update System 2010-03-10 13:37:26 UTC
tar-1.22-5.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/tar-1.22-5.fc11

Comment 27 Fedora Update System 2010-03-12 04:26:57 UTC
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

Comment 28 Fedora Update System 2010-03-27 01:00:24 UTC
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.