Bug 491506 - Amanda cannot be successfully configured with krb5 client authentication
Amanda cannot be successfully configured with krb5 client authentication
Product: Fedora
Classification: Fedora
Component: amanda (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Novotny
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-03-22 05:56 EDT by Martin Smith
Modified: 2009-12-18 04:05 EST (History)
2 users (show)

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

Attachments (Terms of Use)
/var/log/amanda/amandad/amandad.20090525234338.debug (3.37 KB, text/plain)
2009-05-26 03:16 EDT, Enrico Scholz
no flags Details

  None (edit)
Description Martin Smith 2009-03-22 05:56:24 EDT
Description of problem:

I am trying to configure amanda for krb5 authentication and following the instructions on the amanda wiki. The doc says that the xinetd service must run the amandad process as root for krb5:


With this configuration amcheck and amdump fail with a critical error that says the process must not be running as root. If change the xinetd conf to run the process as amandabackup instead of root I get a critical error saying that I must run the process as root when using krb5 authentication.

It therefore seems to be impossible to set up this configuration successfully as both errors say I should be doing the opposite of what I'm doing.

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


How reproducible:


Steps to Reproduce:
1. Install amanda + server package
2. Setup a backup config krb5 auth with amandad as root
3. Modify /etc/services and create /etc/xinetd.d/k5amanda
4. run amcheck on new config

Actual results:

Amanda Backup Client Hosts Check
ERROR: zen: service /usr/libexec/amanda/noop failed: pid 25687 exited with code 1
Client check: 1 host checked in 0.120 seconds.  1 problem found.

The amandad log file contains this as the reason:

** (process:25638): CRITICAL **: running as user "root" instead of "amandabackup"

Expected results:

amcheck succeeds

Additional info:

The xinetd config entry I created for k5amanda:

service k5amanda
	port			= 10082
	socket_type		= stream
	protocol		= tcp
	wait			= no
	user			= root
	group			= disk
	server			= /usr/libexec/amanda/amandad
# Configure server_args for the authentication type you will be using,
# and the services you wish to allow the amanda server and/or recovery
# clients to use.
# Change the -auth= entry to reflect the authentication type you use.
# Add amindexd to allow recovery clients to access the index database.
# Add amidxtaped to allow recovery clients to access the tape device.
	server_args		= -auth=krb5 amdump 
	disable			= no

If I make the user amandabackup instead of root in the above config then I get a different error message.
Comment 1 Daniel Novotny 2009-04-06 08:25:33 EDT
from the docs:

<i>Note that you're running this as root, rather than as your dump user. AMANDA will set it's uid down to the dump user at times it doesn't need to read the keytab file, and give up root permissions entirely before it goes off and runs dump. Alternately you can change your keytab files to be readable by user amanda. You should understand the security implications of this before changing the permissions on the keytab. </i>

did you try to set the permissions of the keytab, when running amanda as the "amandabackup" user?
Comment 2 Martin Smith 2009-04-07 05:17:46 EDT
Yes I tried it with a readable keytab. 

However it doesn't work, there's a hardcoded check in amandad.c at around line 420. If the auth type is krb5 and the userid isn't root it bails out with the error message "Amanda must be run as user 'root' when using 'krb5' authentication.

Like I said, this contradicts the other error message. I can't run it as root and not root at the same time.
Comment 3 Daniel Novotny 2009-04-08 07:44:45 EDT
while trying to analyze the problem myself, I posted the problem description also to upstream mailing list, let's see if they can figure something out
Comment 4 Daniel Novotny 2009-04-14 06:37:27 EDT
did you run the "amcheck" as root? according to upstream, it has to be run as the amandabackup user, even if the server will run as root afterwards
Comment 5 Martin Smith 2009-04-14 07:02:25 EDT
I have tried amcheck as amandabackup. 

There is a lot of scope for confusion here between the various pieces of amanda. Just for clarity here's amcheck run as amandabackup with the server running as root:

-bash-3.2$ id
uid=33(amandabackup) gid=6(disk) groups=6(disk)
-bash-3.2$ amcheck DailySet3
Amanda Tape Server Host Check


Amanda Backup Client Hosts Check
ERROR: zen: service /usr/libexec/amanda/noop failed: pid 21835 exited with code 1
Client check: 1 host checked in 1.114 seconds.  1 problem found.

And here's the other error if I run amcheck as amandabackup with the server running as amandabackup:

-bash-3.2$ amcheck DailySet3
Amanda Tape Server Host Check


Amanda Backup Client Hosts Check
WARNING: zen: selfcheck request failed: recv error in gss loop: tcpm_recv_token: invalid size: amandad: Amanda must be run as user 'root' when using 'krb5' authetication

Client check: 1 host checked in 10.151 seconds.  1 problem found.
Comment 6 Daniel Novotny 2009-04-14 07:56:08 EDT
What do you get if you run '/usr/libexec/amanda/noop' on the command
line? If it start, just type '^D'.
Comment 7 Martin Smith 2009-04-23 05:31:55 EDT
I can run that command without seeing any errors. It just sits there until
I hit Ctrl-D.
Comment 8 Enrico Scholz 2009-05-26 03:16:05 EDT
Created attachment 345391 [details]

here too;

# su - amandabackup -s /bin/sh -c '/usr/libexec/amanda/noop </dev/null'
OPTIONS features=ffffffff9ffeffffffff00;

# /usr/libexec/amanda/noop </dev/null

** (process:3645): CRITICAL **: running as user "root" instead of "amandabackup"


'noop' seems to be called in both variants (see attached logfile).
Comment 9 Bug Zapper 2009-11-18 06:34:38 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 10 Bug Zapper 2009-12-18 04:05:10 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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