Bug 168136 - /usr/sbin/amrecover cannot be executed
Summary: /usr/sbin/amrecover cannot be executed
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-09-12 19:47 UTC by Stephen Walton
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version: 1.27.1-2.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-20 13:09:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Stephen Walton 2005-09-12 19:47:25 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
I have been happily backing up tapes with amanda for a long time, first with a locally compiled version, now with the one shipped with FC4.  For the first time today, I tried to recover a file with /usr/sbin/amrecover and received the error

[root@apollo ~]# /usr/sbin/amrecover
-bash: /usr/sbin/amrecover: Permission denied
[root@apollo ~]# ldd /usr/sbin/amrecover
/usr/bin/ldd: line 124: /usr/sbin/amrecover: Permission denied

This is really very strange.  Every other executable in /usr/sbin is fine.  For example:

[root@apollo ~]# ldd /usr/sbin/amrestore
        linux-gate.so.1 =>  (0x40000000)
        libamtape-2.4.5.so => /usr/lib/libamtape-2.4.5.so (0x00b58000)
        libamanda-2.4.5.so => /usr/lib/libamanda-2.4.5.so (0x00ba1000)
        libm.so.6 => /lib/libm.so.6 (0x00b31000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0x00d2f000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00952000)
        libc.so.6 => /lib/libc.so.6 (0x00a06000)
        /lib/ld-linux.so.2 (0x009e8000)
[root@apollo ~]# /usr/sbin/amrestore
amrestore: Must specify tape-device or holdingfile
amrestore: Usage: amrestore [-b blocksize] [-r|-c] [-p] [-h] [-f fileno] [-l label] tape-device|holdingfile [hostname [diskname [datestamp [hostname [diskname [datestamp ... ]]]]]]

I have tried rebuilding amanda from the source RPM and reinstalling amanda-client, to no avail.

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

How reproducible:
Always

Steps to Reproduce:
1. Execute /usr/sbin/amrecover either as root, amanda, or any other user
  

Actual Results:  "Permission denied"

Expected Results:  The executable should, well, execute.

Additional info:

I do have SELinux enabled in targeted mode on this system, a dual CPU Athlon machine.  Since it is a heavily used server I have not tried disabling SELinux to see if that would fix the problem.  The system in question is a fresh install of FC4, not an upgrade from a previous release.

Comment 1 Jay Fenlason 2005-09-12 21:17:53 UTC
That's odd.  amrecover works fine on my FC4 system.  Can you show the output 
of "ls -lZ /usr/sbin/amrecover" and "id" when logged in as root? 

Comment 2 Stephen Walton 2005-09-12 22:04:10 UTC
[root@apollo ~]# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=root:system_r:unconfined_t
[root@apollo ~]# ls -lZ /usr/sbin/amrecover
-rwxr-x---  amanda   disk     system_u:object_r:amanda_recover_exec_t
/usr/sbin/amrecover

This is the correct context for amrecover according to
/etc/selinux/targeted/contexts/files/file_contexts from selinux-policy-targeted
version 1.25.4-10.

Comment 3 Jay Fenlason 2005-09-13 19:00:39 UTC
AHA!  It's an selinux problem.  I can reproduce the problem by going into 
system-config-securitylevel and setting the SELinux mode to Enforcing. 
 
I'm reassigning this to the SELinux policy maintainers.  In the mean time, for 
a workaround, you can set you SELinux mode to Permissive while doing the 
restore. 

Comment 4 Daniel Walsh 2005-09-19 20:21:10 UTC
Fixed in selinux-policy-*-1.27.1-2.1


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