Steven Bonneville wrote:
Well, sort of. What X.501 says and the LDAP RFCs follow is that an entry
is characterized by exactly one *chain* of structural object classes that
has exactly one structural object class as the most subordinate object
class in the chain...
...Now, we can't add account as an object class of this entry, because it is
a structural object class that is not part of the structural object class
chain connecting inetOrgPerson to top, so we'd end up with two structural
object class chains -- that's illegal.
Just talking this through:
I was looking for where this is specifically stated as illegal. I guess
the answer to this is the X.501 spec (I think it costs money to get
this, though?).
RFC2252 states "The format for representation of object classes is
defined in X.501 [3]. In general every entry will contain an abstract
class ("top" or "alias"), at least one structural object class, and zero
or more auxiliary object classes.". This could be interpreted as
saying: LDAP is based on and follows X.501, unless otherwise specified,
and here is where we specifically state where LDAP differs from X.501,
and X.501 has this limit, but strictly speaking, LDAP does not(?) I
suppose you could also interpret that as allowing multiple structural
objectclasses, as long as they have a common ancestor (the LDAP RFC
doesn't say that, but I suppose that might be more clearly stated in the
X.501 spec?). Sounds like I am stepping into an LDAP/X.50x holy war :)
Thinking about this in a real-world context, given/if multiple
structural objectclasses are illegal, then it seems that the definition
of the account objectclass is poorly thought out (granted, it was
defined long, long ago...) - it makes sense to extend a person entry to
be an account (or vice versa), so that you don't have to have separate
entries for one person to define unix login, "account" info, etc - I
should be able to define a single user all in one entry, so that if I
want to change a users password, grant or remove access to services,
etc, I do it in one place. (maybe a bad example, since account doesn't
include a password, which seems kinda strange itself...) Otherwise, you
defeat part of the purpose of LDAP, and violate some basic tenants of
data design (i.e. avoiding duplication of data, etc).
FWIW, this all started with a discussion of posixAccount, and how to
restrict what hosts a user can log into. My initial thought was to just
add the account objectclass to a user to have a host attribute for a
user (wouldn't have to extend the schema, and could use existing
standard oc's) , but then you run into the multiple structural oc's
issue. I guess the "right" answer would be to define a non-standard
objectclass that is an extention of person, posixaccount, or whatever
that allows the host attribute.
- Jeff
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
