[OpenAFS] Preferred method for turning MIT Kerberos tickets
into AFS tokens in Linux
Kevin
openafs@gnosys.biz
Tue, 23 Nov 2004 21:56:24 -0500
On Tue, 2004-11-23 at 13:22 -0500, Ken Hornstein wrote:
> >I did manage to build aklog and asetkey for
> >i386_linux24, but it was just lucky for me that it worked because the
> >make pooped out after building those executables.
>
> I wouldn't call it "luck" ... those are likely the only ones you really
> need.
>
If that came across as a disparaging remark then I apologize. I didn't
mean it that way. I'm incredibly grateful to you Ken for your faq and
aklog and so much more. You've helped me a great deal both directly and
indirectly.
> (I don't really recall that the autoconf problems were _that_ terrible,
> personally; when I ran into it I just edited the generated Makefile and
> fixed the few things that needed fixing).
>
Thanks for mentioning this.
With this to go on, I just removed some of the items in the PROGS
variable in the Makefile, and thereby got aklog to build, but asetkey
fails with:
root@hermes src # make
gcc -g -O2 -I/usr/include -I/usr/afsws/include -DPACKAGE_NAME=\"afs-krb5
\" -DPACKAGE_TARNAME=\"afs-krb5\" -DPACKAGE_VERSION=\"1.4\"
-DPACKAGE_STRING=\"afs-krb5\ 1.4\" -DPACKAGE_BUGREPORT=
\"kenh@cmf.nrl.navy.mil\" -DAFS=1 -DAFS_INT32=1 -DAFS_TRY_FULL_PRINC=1
-DHAVE_DAEMON=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDLIB_H=1
-DHAVE_MEMORY_H=1 -DHAVE_PATHS_H=1 -DHAVE_MALLOC_H=1 -DHAVE_STRERROR=1
-DRETSIGTYPE=void -DALLOW_REGISTER -c -o asetkey.o asetkey.c
asetkey.c: In function `main':
asetkey.c:80: error: too few arguments to function `afsconf_AddKey'
make: *** [asetkey.o] Error 1
I looked in 1.3.74 afs/cellconfig.h for the function prototype and it's
true. The prototype calls for 4 parameters and the code in asetkey.c
calls the function with 3. I looked in cellconfig.c for the function
definition and it looked like it might be safe to just add a "0" as the
fourth parameter to the function call in asetkey.c and this does get me
an executable asetkey, but I have no idea if my change caused a logical
error that will result in buggy behavior. I really don't want to lose
data. Could someone here comment on the safety of that change? Is
there any risk of it causing file corruption or loss?
1.3.74 afs/cellconfig.h:
extern struct afsconf_dir *afsconf_Open(register const char *adir);
extern int afsconf_CellApply(struct afsconf_dir *adir,
int (*aproc) (struct afsconf_cell * cell,
char *arock,
struct afsconf_dir * dir),
char *arock);
extern int afsconf_CellAliasApply(struct afsconf_dir *adir,
int (*aproc) (struct afsconf_cellalias
*
alias, char *arock,
struct afsconf_dir *
dir),
char *arock);
extern int afsconf_GetExtendedCellInfo(struct afsconf_dir *adir,
char *acellName, char *aservice,
struct afsconf_cell *acellInfo,
char clones[]);
extern int afsconf_GetAfsdbInfo(char *acellName, char *aservice,
struct afsconf_cell *acellInfo);
extern int afsconf_GetCellInfo(struct afsconf_dir *adir, char
*acellName,
char *aservice,
struct afsconf_cell *acellInfo);
extern int afsconf_GetLocalCell(register struct afsconf_dir *adir,
char *aname, afs_int32 alen);
extern int afsconf_Close(struct afsconf_dir *adir);
extern int afsconf_IntGetKeys(struct afsconf_dir *adir);
extern int afsconf_GetKeys(struct afsconf_dir *adir,
struct afsconf_keys *astr);
extern afs_int32 afsconf_GetLatestKey(struct afsconf_dir *adir,
afs_int32 * avno, char *akey);
extern int afsconf_GetKey(struct afsconf_dir *adir, afs_int32 avno,
char *akey);
extern int afsconf_AddKey(struct afsconf_dir *adir, afs_int32 akvno,
char akey[8], afs_int32 overwrite);
extern int afsconf_DeleteKey(struct afsconf_dir *adir, afs_int32 akvno);
struct rx_securityClass;
extern afs_int32 afsconf_ClientAuth(struct afsconf_dir *adir,
struct rx_securityClass **astr,
afs_int32 * aindex);
1.2.11 afs/cellconfig.h:
extern struct afsconf_dir *afsconf_Open();
extern afs_int32 afsconf_ClientAuth();
extern afs_int32 afsconf_Authenticate();
extern int afsconf_GetKey();
struct afsconf_servPair {
char *name;
int port;
};
The offending code (with some context) in asetkey.c is:
74 if (key->length != 8) {
22 75 printf("Key length should be 8, but is really
%d!\n",
76 key->length);
77 exit(1);
78 }
79
>>> 80 code = afsconf_AddKey(tdir, kvno, key->contents);
81 if (code) {
82 printf("setkey: failed to set key, code %d.\n",
code);
83 exit(1);
84 }
85 krb5_free_principal(context, principal);
86 krb5_free_keyblock(context, key);
87 }
88 else if (strcmp(argv[1], "delete")==0) {
My new line 80 is:
code = afsconf_AddKey(tdir, kvno, key->contents, 0);
Is that a safe change to make?
Thanks for your reply, Ken. As you have so often in the past, you got
me past being stumped on this problem too.
But my real question here was just on the issue of whether or not aklog
is still the generally preferred method for doing this. Is it? Am I
right in thinking that everyone who's using OpenAFS with Kerberos as an
authentication source is doing the same thing that I've done here
whenever they add a new client machine or upgrade the software? They
get your tarball, configure it, modify the Makefile, modify asetkey.c,
build aklog and asetkey, and then they're up and running? Now that I
have the problem solved I'm content for now, but I'm still curious about
this issue because I'm sure I'll be asking this question (of myself and
also perhaps here too) in another 6 or 8 months when I want to make some
other alterations.
Thanks again for the help.
-Kevin
http://www.gnosys.us