[Fedora-directory-users] Wishlist

[Rich Megginson]

Jeff Clowser wrote:

> 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 :)

I'm sure the folks on the ldap umich list will be happy to provide their 
interpretations :-)

>
> 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).

The account objectclass was poorly designed IMHO.

>
> 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.

We are going to be visiting this issue for our next release.  In the new 
RFC2307bis (which we will somehow support) 
http://www.ietf.org/internet-drafts/draft-howard-rfc2307bis-01.txt - 
posixAccount and most of the other key objectclasses that you might want 
to "mix in" with existing structural objectclasses are defined as 
AUXILIARY specifically for this reason.  As far as the problem with the 
account objectclass - one of the key things needed is the "host" 
attribute, for host based access restriction.  I know that some tools 
(Directory Administrator) assume that, if a search is done for 
objectclass=posixAccount, the host attribute should be among them.  I 
propose the creation of a new objectclass that will be AUXILIARY and 
also be a subclass of posixAccount.  This objectclass will contain the 
"host" attribute (other attributes?).  In order to make host based 
access restriction work, you would simply add this objectclass and host 
attribute to any existing user, even if they already have the 
posixAccount objectclass.  I'm not sure what a good name for this 
objectclass would be - perhaps posixAccountExt or ???  At any rate, 
applications that use the search filter (objectclass=posixAccount) to 
get entries that contain the host attribute would continue to work.  
This would simplify new account creation because you could just use the 
new objectclass instead of posixAccount and it would inherit all of the 
posixAccount attributes.

>
> - Jeff
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3312 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20050826/34ca1b5d/attachment.bin>