| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
Fix indentation and remove an inappropriate comment in add_subscriptions(),
both of which were the result of a botched merge a long time ago. The
actual logic was merged correctly and so does not change.
|
|
|
|
|
|
|
| |
The result of Z_krb5_verify_cksum is supposed to be nonzero on success and
0 on failure. But if krb5_crypto_init() failed, we were returning the
resulting error code, effectively accepting any checksum, when instead we
should reject the checksum since we cannot verify it.
|
|
|
|
|
| |
Fix a leak in which we fail to free a Kerberos authentication context
in ZCheckSrvAuthentication if getting or setting the context flags fails.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From -c shadow on 15-Nov-2011, discussing a problem where some notices
received from other realms were causing clients to crash:
So, the packet that crashed my client had extra garbage beyond what
should have been the end of the packet. So z_multinotice was 0/61,
but the packet was longer than 61. Which means the logic that should
have treated this as an unfragmented notice (because partof ==
z_message_len) did not trigger.
So a holelist gets created, with enough storage for partof, and then
Z_AddNoticeToEntry is called to copy z_message_len (> partof) bytes
into it.
So, I don't know why your client, or the server, or something, is sending
packets longer than the message length, but I don't think I actually want
to just discard those, because then "legitimate" messages would vanish.
Instead, if part + notice->z_message_len > partof, I just want to ignore
the extra.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug report from dkindred in libzephyr affecting amd64_fc5:
There's a bug in libzephyr (introduced in version
zephyr-064) that is causing tzc to fail on amd64_fc5:
In /afs/cs/misc/zephyr/src/zephyr-064/lib/ZRecvNot.c line
33, 'nextq' is tested without being initialized (see code
below).
I imagine the appropriate fix is to put that "if (!nextq)"
test just *after* the "nextq = Z_GetFirstComplete();" line
instead of just before.
- Darrell
|
|
|
|
|
|
|
| |
Z_GetFirstComplete() can return NULL; in that case, we don't want to
dereference the pointer it returns.
Extracted from Andrew zephyr/064; authorship uncertain.
|
|
|
|
|
|
|
|
|
|
| |
tkt_lookup() is supposed to quickly obtain a ticket for a foreign realm
if we already have a usable one, and quickly fail otherwise. Sending a
request to a KDC and waiting for a response, as krb5_get_credentials()
may do, defeats the purpose of tkt_retrieve() retrying failed requests
in the background. So, use krb5_cc_retrieve_cred() instead.
Extracted from Andrew zephyr/063
|
|
|
|
|
|
|
|
|
| |
If we want to receive login/logout notices for a user in another realm,
we need to subscribe to them in that realm.
Extracted from Andrew zephyr/058, which reverts a change to client-side
interrealm support that was inadvertently introduced when importing new
code from Athena.
|
|
|
|
|
|
| |
We need the bytes, no modern client uses it, and it's inherently a
security vulnerability. For those clients that do use it, provide a link
to a page on the zephyr wiki that explains the issue.
|
|
|
|
|
| |
memset new notice objects in subscr.c (really needed now since all
ZFormat* routines require z_num_hdr_fields to be valid or 0.)
|
|
|
|
|
|
|
|
| |
realm_sendit is responsible for sending notices that do not have useful
realm authentication, either because they are not authentic, or because
of kerberos problems acquiring a ticket for the foreign zephyr realm. In
either case, any authentication in the notice will not be usable to the
foreign server, and ought to be stripped out.
|
|
|
|
|
|
|
| |
Have Z_FormatRawHeader call Z_ZcodeFormatRawHeader to reduce duplication
and error. Z_FormatRawHeader was previously adding headers 17 and 18
unconditionally, which was not proper for a server forwarding an unauth
message.
|
| |
|
| |
|
|
|
|
| |
To my knowledge, this hasn't been enabled by anyone in ages
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
devscript will mostly be required by the release mechanisms,
but git will be required for figuring out a build-time version number
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In addition to the packet length problem discussed last night, the
realm_auth_sendit_nacked refactor also had a cut-n-paste error. In the
unfragmented case, it passed in partnotice.z_uid instead of
newnotice.z_uid. In that branch of the if, partnotice is
uninitialized... My (derrick's) servers are no longer constantly
complaining (in new debug code) that realm_nack_cancel couldn't find
the nack to dequeue, so I think I'm done with this problem.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
So that the packaging will still work with the libtoolize on lenny
|
| |
|
| |
|
|
|
|
|
| |
i.e. don't keep generated or foreign stuff in our source tree.
As a side effect, this lets us use a libtool, etc. from this century
|
|
|
|
|
| |
Does everything still work if configure checks for iconv_open rather
than the mysterious libiconv_open? Tune into an autobuilder near you...
|
| |
|
|
|
|
| |
Fixes #58
|
| |
|
|
|
|
| |
Fixes #72
|
|
|
|
| |
So it can check for a keytab rather than a srvtab. Fixes #43.
|
|
|
|
|
|
|
| |
The fact that the Heimdal and MIT APIs are subtly different strikes again.
I am honestly starting to wonder if they make it look this similar just
to frustrate people; I only don't believe it because neither team seems
like that sort of person. Fixes #74.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Since these are constants used in the protocol be explicit about what values
the C compiler is assigning them, and that they can't be arbitrarily
rearranged.
Also, since we were promising strings for describing them in zephyr.h
actually define the array.
|
| |
|
| |
|