[OpenAFS-devel] hidden commands

Marcus Watts mdw@spam.ifs.umich.edu
Thu, 07 Jun 2007 22:32:02 -0400


"Steven Jenkins" <steven.jenkins@gmail.com> writes:
...
> - admin_tools.c: kas getpassword/getpasswd(which I couldn't get to work --
...
> [admin@sjfcafs11 ]$ kas getpassword -name admin
> kas:getpassword: caller not authorized getting admin's password via loopback
> connection to GetPassword
> 
> I also tried unsuccessfully as root, with admin's token.

Root or not makes no differences to a client/server program.  Nor should
it.  Just because you have root on your mongrel frankenstein linux box
in some dark cubby hole of your great <local institution> does not mean
the guys in white hats should trust you.

On the *other* hand; your IP address does matter, & "kas getpassword"
should only work on connections made via "localhost" -- ie, on the host
running kaserver.  kas has code in it to do this, plus error messages
to point you this way.

AND...  you have to have a special build of kaserver with "GETPASSWORD"
turned on.  Otherwise kamGetPassword in src/kauth/kaprocs.c is very
boring and always returns KANOAUTH.

At umich.edu when we were running kaserver, we ran with "GETPASSWORD"
enabled.  We used it so that we could rename principals -- ptserver has a
rename option, but kaserver doesn't.  With special code running on the kdc
though, we could fetch the key, save it, delete the old ka instance,
create a new ka instance, and restore the user's key.  Since k4 keys didn't
depend on the principal (only the cell), this worked.

kaserver today has another way to do this as well; "kamGetEntry" will
return the key for administrative users.  "kas examine -showkey" will
do this.  This is a "new" feature (well, new somewhere in late transarc),
AFS 3.4 would only do this if security was turned off in the cell.
The people who made this change were clearly a lot less paranoid than
the people who worked on the GetPassword rpc.

				-Marcus Watts