Red Hat Bugzilla – Bug 1135427
kadmin.local -q with wrong value in -e option doesn't return nonzero return code
Last modified: 2016-11-03 16:22:07 EDT
Description of problem: kadmin.local -q with wrong value in -e option doesn't return nonzero return code [test]kadmin.local -r EXAMPLE.COM -q "addprinc -randkey -e aes256-cts,aes128-cts kvnoprinc" Authenticating as principal root/admin@EXAMPLE.COM with password. add_principal: Invalid argument while parsing keysalts aes256-cts,aes128-cts usage: add_principal [options] principal options are: [-x db_princ_args]* [-expire expdate] [-pwexpire pwexpdate] [-maxlife maxtixlife] [-kvno kvno] [-policy policy] [-clearpolicy] [-randkey] [-pw password] [-maxrenewlife maxrenewlife] [-e keysaltlist] [{+|-}attribute] attributes are: allow_postdated allow_forwardable allow_tgs_req allow_renewable allow_proxiable allow_dup_skey allow_tix requires_preauth requires_hwauth needchange allow_svr password_changing_service ok_as_delegate ok_to_auth_as_delegate no_auth_data_required where, [-x db_princ_args]* - any number of database specific arguments. Look at each database documentation for supported arguments [test]echo $? 0 Version-Release number of selected component (if applicable): krb5-server-1.11.3-49.el7 How reproducible: always Steps to Reproduce: 1.kadmin.local -r EXAMPLE.COM -q "addprinc -randkey -e aes256-cts,aes128-cts kvnoprinc" 2.echo $? 3. Actual results: 0 Expected results: nonzero Additional info: cpw has incorrect behavior as well kadmin.local -r EXAMPLE.COM -q "cpw -randkey -keepold -e aes256-cts,aes128-cts kvnoprinc" Authenticating as principal root/admin@EXAMPLE.COM with password. change_password: Invalid argument while parsing keysalts aes256
I don't see that kadmin makes any guarantees about its exit status. Its implementation appears to discard any errors encountered while processing commands, so we're potentially talking about much more than just these two commands and the -e flag.
(In reply to Nalin Dahyabhai from comment #1) > I don't see that kadmin makes any guarantees about its exit status. Its > implementation appears to discard any errors encountered while processing > commands, so we're potentially talking about much more than just these two > commands and the -e flag. Just for the log: One idea I had was to implement kadminsh, a kadmin version based on AT&T AST's libshell (which provides a POSIX shell (ksh93) as shared library) and implement the kadmin subcommands as shell builtins... that would allow getting the proper return status for each subcommand and even add control over the code flow when multiple kadmin subcommands are used. Problem is getting time allocated for this project... implementing it is easy but getting the neccesary infrastructure into Fedora is a man-week of work.
See http://krbdev.mit.edu/rt/Ticket/Display.html?id=7991 for a proposed upstream enhancement to address this issue (not using libshell).
If memory serves, this landed in the 1.14 we're passing around.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2591.html