Red Hat Bugzilla – Bug 491506
Amanda cannot be successfully configured with krb5 client authentication
Last modified: 2009-12-18 04:05:10 EST
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: http://wiki.zmanda.com/index.php/Kerberos_authentication 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): 2.6.0-p2 How reproducible: Always. 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.
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?
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.
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
hello, 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
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.
What do you get if you run '/usr/libexec/amanda/noop' on the command line? If it start, just type '^D'.
I can run that command without seeing any errors. It just sits there until I hit Ctrl-D.
Created attachment 345391 [details] /var/log/amanda/amandad/amandad.20090525234338.debug 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).
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.