[OpenAFS] Any way to create srvtabs for use with kaserver...
Eric Knudstrup
eric@knudstrup.org
Wed, 06 Mar 2002 18:26:28 -0800 (PST)
Thanks for the reply about the library ordering. I was coding a few hours after
I should have been sleeping.
Ok, I have something mocked up for the principal creation routine, but I keep
getting an error message:
./afssvcnew httpd temp.srvtab
Password:test
Failed to create principal: RPC interface mismatch (-450)
#include <afs/stds.h>
#include <afs/kautils.h>
#include <rx/xdr.h>
#include <pwd.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#define BUFSIZ 256
/*
afssvcnew <principal> <key filename>
This program does the following:
1. Creates a DES key
2. Calls the kaserver to create a new principal with the key
3. Saves the key off into a srvtab/keytab for use with afssvcd
*/
int main(int argc, char *argv[])
{
char *lcell, *reason;
char ch;
int fd, n, code;
struct ktc_encryptionKey key;
struct ubik_client *conn = NULL;
char passwd[BUFSIZ];
char lrealm[MAXKTCREALMLEN]; /* uppercase copy of local cellname */
struct passwd *pw;
if(argc!=3) {
fprintf(stderr, "%s <principal> <key filename>\n"
" principal - Name of principal you want to use\n"
" key filename - Name of file to store it in\n");
exit(1);
}
code = ka_Init(0);
if(code) {
fprintf(stderr, "Failed to connect to local cell\n");
exit(1);
}
lcell = ka_LocalCell();
if(!lcell) {
fprintf(stderr, "Failed to get local cell name\n");
}
code = ka_AuthServerConn(lcell, KA_MAINTENANCE_SERVICE, NULL, &conn);
if(code) {
fprintf(stderr, "Got code from ka_AuthServerConn: %d\n", code);
exit(1);
}
code = ubik_Call (KAM_GetRandomKey, conn, 0, &key);
if(code) {
fprintf(stderr, "Failed to get key\n");
exit(1);
}
printf("%p\n", key);
code = ubik_Call (KAM_CreateUser, conn, 0, argv[1], NULL, key);
if(code) {
fprintf(stderr, "Failed to create principal: %s\n", error_message(code));
exit(1);
}
/* .... */
}
Quoting Marcus Watts <mdw@umich.edu>:
> Eric Knudstrup <eric@knudstrup.org> writes:
> > To: openafs-info@openafs.org
> > Subject: Re: [OpenAFS] Any way to create srvtabs for use with
> kaserver...
> > Message-ID: <1015125634.3c81968247711@knudstrup.org>
> > From: Eric Knudstrup <eric@knudstrup.org>
> > Date: Sat, 02 Mar 2002 19:20:34 -0800 (PST)
> >
> > So, could I use KAM_GetRandomKey(), use that for KAM_CreateUser(),
> then save
> > the
> > EncryptionKey/struct ktc_encryptionKey off in a -r-------- file?
> > Then I'm assuming I could use ka_Authenticate, or is there a better
> function?
> > I had another question. Is there a function that will give me a
> PAG?
> > The API reference PDF is pretty vague...
>
> Sure you can do that. Once you've created your principal,
> you could also make a K4 srvtab and use K4 library functions
> instead. A K4 srvtab looks something like this:
>
> 0000000 s p e r l \0 t e s t \0 U M I C
> H
> 0000020 . E D U \0 003 277 320 I 313 001 217 032 z
> 0000036
>
> Where
> principal's name: sperl.test@UMICH.EDU
> kvno:
3
> key:
BFD049CB018F017A
>
> That is:
> null terminated name
> null terminated instance
> null terminated realm (upper-case)
> 1 byte kvno
> 8 bytes key
>
> multiple keys can be put in one srvtab -- just concatenate
> them together.
>
> The AFS library functions don't know about srvtabs (at least,
> not out of the box). It's easy enough to teach them how
> to use one -- it's even possible to have an RX server (as opposed
> to an AFS client application) that uses a srvtab.
>
> To make a pag, call "setpag". Or "lsegpag", if you want to avoid
> linking in the rmtsys stuff. Beware: don't call setpag too often.
> If a bunch of them come in at once, the kernel may insert sleeps
> to avoid executing more than one setpag per second. If you have
> an application that expects to authenticate itself as several
> different
> things, it's better to do one setpag and reuse the pag for each
> authentication. If you are always using one cell, you don't need
> to do any cleanup between uses. If you plan on something more
> complicated, you might want to unlog and clean out tokens
> in the kernel. It is good practice to unlog when you are through.
> This avoids stuffing up kernel tables with lots of not quite
> dead tokens. The unlog is done with a pioctl -- look at the AFS
> source for the "unlog" cmd to find out what it's called, and
> what include files you need.
>
>
-Marcus Watts
>
UM ITCS Umich Systems Group
>