[3850] in Kerberos
v5srvtab lossage ... anyone seen this?
daemon@ATHENA.MIT.EDU (*Hobbit*)
Fri Sep 16 07:34:24 1994
To: kerberos@MIT.EDU
Date: 16 Sep 1994 07:01:35 EDT
From: hobbit@elf.com (*Hobbit*)
I'm building k5beta4. I got the kdc running, a few tickets created,
I can kinit. The platform is a sunos 4.1.3 sparc.
kdb5_edit: "xst instance principal" blows chow with "bad file number" while
trying to write the keytab.
Before I explain further, if you've run up against this one, please let me
know what's going on and what the fix is. I gave it an honest five hours
of study, I feel like I've done my part, and I'm stumped.
Nitty-gritty: It has to do with posix file locking using fcntl(). The
chain of suspects is something like this. I'm playing very fast and
loose with routine names here; it's *so* goddamn convoluted and my notes
are somewhat hasty:
lib/krb5/keytab/ktadd.c: id -> ops -> add
lib/krb5/keytab/file/ktf_add.c: krb5_ktfile_add (id, entry)
lib/krb5/keytab/file/ktf_util.c:
ktfileint_openw ()
ktfileint_open (id, mode) /* mode is EXCLUSIVE_LOCK or such */
create_secure_file /* succeeds */
fopen (said file, "rb+) /* succeeds */
lib/krb5/os/lock_file.c: krb5_lock_file ()
fcntl (fileno (filep), F_SETLKW, &lock_arg)
This last item is what generates errno == EBADF, and it all unwinds. I get
a zero-length keytab file with the correct name, mode 0600.
All the manpage says about F_SETLKW bailing out like this is the case
where the "process has insufficient permissions" wrt the file. I *own*
the file, or I'm root, or both, so it's lying.
POSIX_ME_HARDER again and again...
_H*
