Bug 165830 - targeted policy stops amanda from backing up / with tar
targeted policy stops amanda from backing up / with tar
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
4
All Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-12 12:54 EDT by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.27.1-2.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-28 10:21:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2005-08-12 12:54:51 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b3) Gecko/20050729 Fedora/1.1-0.2.5.deerpark.alpha2 Firefox/1.0+

Description of problem:
Trying to back up the root filesystem with Amanda and GNU tar on a box running with the default targeted policy causes the following errors to be mentioned in the Amanda report, such that the backup is regarded as failed and discarded:

/-- cuca.lsd.i / lev 0 FAILED [/bin/tar returned 2]
sendbackup: start [cuca.lsd.ic.unicamp.br:/ level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
? gtar: ./sys: Warning: Cannot stat: Permission denied
? gtar: ./net: Warning: Cannot stat: Permission denied
? gtar: ./proj: Warning: Cannot stat: Permission denied
? gtar: ./network: Warning: Cannot stat: Permission denied
? gtar: ./h: Warning: Cannot stat: Permission denied
? gtar: ./p: Warning: Cannot stat: Permission denied
? gtar: ./home: Warning: Cannot stat: Permission denied
? gtar: ./home-ext: Warning: Cannot stat: Permission denied
? gtar: ./misc: Warning: Cannot stat: Permission denied
? gtar: ./n: Warning: Cannot stat: Permission denied
? gtar: ./selinux: Warning: Cannot stat: Permission denied
? gtar: ./proc: Cannot savedir: Permission denied
? gtar: ./tmp/mapping-ra001973: Warning: Cannot stat: Permission denied
? gtar: ./tmp/mapping-ra030042: Warning: Cannot stat: Permission denied
? gtar: ./tmp/OSL_PIPE_2943_SingleOfficeIPC_f13758d1e1df484c81fd284b24833718: Warning: Cannot stat: Permission denied
? gtar: ./tmp/.gdm_socket: Warning: Cannot stat: Permission denied
? gtar: ./tmp/OSL_PIPE_4867_SingleOfficeIPC_973713a88eba595cd32ad8b10b7ef44: Warning: Cannot stat: Permission denied
? gtar: ./tmp/mapping-tiemi: Warning: Cannot stat: Permission denied
? gtar: ./tmp/mapping-ra027606: Warning: Cannot stat: Permission denied
? gtar: ./tmp/.X11-unix/X0: Warning: Cannot stat: Permission denied
? gtar: ./tmp/.font-unix/fs7100: Warning: Cannot stat: Permission denied
? gtar: ./var/gdm/.gdmfifo: Warning: Cannot stat: Permission denied
? gtar: ./var/lib/nfs/rpc_pipefs: Warning: Cannot stat: Permission denied
? gtar: ./var/run/acpid.socket: Warning: Cannot stat: Permission denied
? gtar: ./var/run/sdp: Warning: Cannot stat: Permission denied
? gtar: ./var/run/.iroha_unix/IROHA: Warning: Cannot stat: Permission denied
? gtar: ./var/run/dbus/system_bus_socket: Warning: Cannot stat: Permission denied
? gtar: ./var/run/iiim/.iiimp-unix/9010: Warning: Cannot stat: Permission denied
? gtar: ./var/run/quagga/zserv.api: Warning: Cannot stat: Permission denied
? gtar: ./var/run/quagga/zebra.vty: Warning: Cannot stat: Permission denied
? gtar: ./proc: Warning: Cannot savedir: Permission denied

Many of the failed stats are for separate mount-points.  The ones that look unfamiliar are automount-managed ones.  Looks like tar, as started by sendbackup, needs more access than it gets.  I don't think it should be limited in what it can stat or read in any way, otherwise it won't be actually backing up all the data.

Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.25.3-12

How reproducible:
Always

Steps to Reproduce:
1.Try to back up the root filesystem of any FC4-running box using the targeted policy, using Amanda+tar

Actual Results:  It fails, as above

Expected Results:  It worked in FC3

Additional info:
Comment 1 Daniel Walsh 2005-08-15 13:15:39 EDT
Could you attach the avc messages from /var/log/audit/audit.log or
/var/log/messages?
Comment 2 Alexandre Oliva 2005-08-16 14:18:55 EDT
This is only example from a session that displayed all of the above errors.  I
wonder why none of the others made it to the logs.

type=AVC msg=audit(1123291981.134:1169): avc:  denied  { getattr } for 
pid=32126 comm="tar" name=".gdmfifo" dev=dm-0 ino=2511528
scontext=system_u:system_r:amanda_t tcontext=system_u:object_r:xserver_log_t
tclass=fifo_file
type=SYSCALL msg=audit(1123291981.134:1169): arch=40000003 syscall=196
success=no exit=-13 a0=8d90498 a1=bfd57534 a2=235ff4 a3=8 items=1 pid=32126
auid=4294967295 uid=0 gid=6 euid=0 suid=0 fsuid=0 egid=6 sgid=6 fsgid=6
comm="tar" exe="/bin/tar"
type=AVC_PATH msg=audit(1123291981.134:1169):  path="/var/gdm/.gdmfifo"
type=CWD msg=audit(1123291981.134:1169):  cwd="/"
type=PATH msg=audit(1123291981.134:1169): item=0 name="./var/gdm/.gdmfifo"
flags=0  inode=2511528 dev=fd:00 mode=010660 ouid=0 ogid=0 rdev=00:00


Another run, backing up a filesystem containing home directories, displayed
errors like this:

type=AVC msg=audit(1124070354.148:98547): avc:  denied  { getattr } for 
pid=15239 comm="tar" name="licq_fifo" dev=dm-2 ino=390184
scontext=system_u:system_r:amanda_t tcontext=system_u:object_r:user_home_t
tclass=fifo_file
type=SYSCALL msg=audit(1124070354.148:98547): arch=40000003 syscall=196
success=no exit=-13 a0=8f5c258 a1=bf9ca624 a2=98fff4 a3=9 items=1 pid=15239
auid=4294967295 uid=0 gid=6 euid=0 suid=0 fsuid=0 egid=6 sgid=6 fsgid=6
comm="tar" exe="/bin/tar"
type=AVC_PATH msg=audit(1124070354.148:98547): 
path="/l/home/lsd/breiden/.licq/licq_fifo"
type=CWD msg=audit(1124070354.148:98547):  cwd="/l/home"
type=PATH msg=audit(1124070354.148:98547): item=0
name="./lsd/breiden/.licq/licq_fifo" flags=0  inode=390184 dev=fd:02 mode=010600
ouid=60096 ogid=500 rdev=00:00

There was another entry for another fifo_file, also with context user_home_t.  I
wonder if something is blocking getattr on fifo_files that shouldn't.

Other than that, it appears that most other problems are related with mount
points that don't have selinux contexts associated with them.  Amanda-started
tar needs to be able to at least stat them in order to tell that they're
separate filesystems and not descend into them.
Comment 3 Stephen Walton 2005-08-17 15:10:59 EDT
As a long time Amanda user who just updated my backup server from FC1 to FC4,
I'm seeing the same error.  The ones about failing to stat various sockets and
named pipes are ones I've seen before, and still see when backup up /home for
example, and they seem to be non-fatal.  The fatal one is

./proc:  Cannot savedir: Permission denied

which causes tar to exit with status 2.
Comment 4 Daniel Walsh 2005-08-25 15:41:03 EDT
Fixed in selinux-policy-targeted-1.25.4-10
Comment 5 Alexandre Oliva 2005-08-28 10:33:09 EDT
The `savedir' problem is indeed fixed (thanks!), but the messages about being
unable to stat the named pipes is a bit annoying, couldn't this be fixed as well?
Comment 6 Daniel Walsh 2005-08-29 07:38:53 EDT
Are you seeing additional AVC messages?

Dan
Comment 7 Alexandre Oliva 2005-08-29 10:11:51 EDT
No, nothing else.  Not even messages like the ones in Comment #2, although tar
still reports they failed to stat().

Is it possible to enable logging even for failed events that have logging disabled?
Comment 8 Daniel Walsh 2005-09-19 16:20:37 EDT
Fixed in selinux-policy-*-1.27.1-2.1
Comment 9 Alexandre Oliva 2005-10-28 10:21:13 EDT
Confirmed, thanks!

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