Bug 510649 - Restore of tar archive blocked
Summary: Restore of tar archive blocked
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-10 03:59 UTC by David Highley
Modified: 2009-09-04 15:31 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-04 15:31:10 UTC
Type: ---


Attachments (Terms of Use)

Description David Highley 2009-07-10 03:59:32 UTC
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

Comment 1 Daniel Walsh 2009-07-10 12:22:16 UTC
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.

Comment 2 David Highley 2009-07-10 13:24:47 UTC
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.

Comment 3 Daniel Walsh 2009-07-10 13:48:55 UTC
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.

Comment 4 David Highley 2009-07-10 14:11:02 UTC
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.

Comment 5 Daniel Walsh 2009-07-10 14:39:06 UTC
What files was the tar complaining about for labeling?

Comment 6 David Highley 2009-07-10 16:48:08 UTC
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

Comment 7 Daniel Walsh 2009-07-10 19:38:49 UTC
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

Comment 8 David Highley 2009-07-11 02:05:54 UTC
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"


Note You need to log in before you can comment on or make changes to this bug.