[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Heimdal PATCH] LDAP backend support for OpenLDAP 2.1.x



On Thu, 2003-05-29 at 06:59, Luke Howard wrote:
> 
> There's another, subtle bug in the LDAP backend that Andrew Bartlett
> of the SAMBA team discovered: storing HDBFlags as an integer is both
> compiler and byte-order dependent.
Hi Luke!

Are you taking about this assignment in hdb-ldap.c (from the
LDAP_message2entry function)

/*******/

    values = ldap_get_values((LDAP *) db->db, msg, "krb5KDCFlags");
    if (values != NULL) {
	tmp = strtoul(values[0], (char **) NULL, 10);
	if (tmp == ULONG_MAX && errno == ERANGE) {
	    krb5_set_error_string(context, "strtoul: could not convert flag");
	    ret = ERANGE;
	    goto out;
	}
    } else {
	tmp = 0;
    }
    memcpy(&ent->flags, &tmp, sizeof(HDBFlags));

/*********/

ent->flags has the HDBFlags type:

typedef struct HDBFlags {
  unsigned int initial:1;
  unsigned int forwardable:1;
  unsigned int proxiable:1;
  unsigned int renewable:1;
  unsigned int postdate:1;
  unsigned int server:1;
  unsigned int client:1;
  unsigned int invalid:1;
  unsigned int require_preauth:1;
  unsigned int change_pw:1;
  unsigned int require_hwauth:1;
  unsigned int ok_as_delegate:1;
  unsigned int user_to_user:1;
  unsigned int immutable:1;
} HDBFlags;

I think the same thing happens with  the LDAP_entry2mods funtion.

Because I am implementing the RFC 3244 set password protocol in kpasswdd
and I'm having problems with the mapping between the value stored in the
LDAP server and the mapping with the HDBFlags structure because this is
compiler dependent?
 
I'll try to fix this.

> 
> -- Luke
> 
> --
> Luke Howard | PADL Software Pty Ltd | www.padl.com