Bug 510649 - Restore of tar archive blocked
Restore of tar archive blocked
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2009-07-09 23:59 EDT by David Highley
Modified: 2009-09-04 11:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-04 11:31:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Highley 2009-07-09 23:59:32 EDT
Description of problem:
Restore of tar archive blocked

Version-Release number of selected component (if applicable):

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
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 08:22:16 EDT
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 09:24:47 EDT
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 09:48:55 EDT
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 10:11:02 EDT
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 10:39:06 EDT
What files was the tar complaining about for labeling?
Comment 6 David Highley 2009-07-10 12:48:08 EDT
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 15:38:49 EDT
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-10 22:05:54 EDT
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

getfattr -n security.selinux export/home/dhighley/.fonts
# file: export/home/dhighley/.fonts

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