Re: [ldapext] DBIS commentary

[Jordan Brown <[e-mail]>]

On 12/1/2015 2:13 AM, Bannister, Mark wrote:
>
> > On the case-sensitivity front:  we have a pretty fundamental disagreement.  I 
> believe that UNIX names
>
> > must eventually become case-insensitive, that it is only a matter of time 
> until they do.
>
> Yes, you're right, this is a pretty fundamental disagreement.  As I don't see 
> anyone else entering the
>
> debate supporting case sensitivity, I fear this will fail on a standards track.  
> I may just keep the
>
> software available as an alternative, and those who want it can use it, but I 
> think any hopes I had
>
> that DBIS might one day be a standard have just been dashed.  I will continue to 
> answer some
>
> of your points anyway, just for completion.  Those who agree with me are either 
> a) not speaking
>
> up or b) not reading this mailing list.
>

Do note again that RFC 4876 mapping would let you redirect the clients to use a 
custom case-sensitive attribute, or attributes from different auxiliary classes.

> However, I would point out that you will meet resistance (and/or disgruntled 
> customers after the
>
> fact) if you attempt to change UNIX to be case-insensitive.
>

For the particular case of user names, I'll note that you're the first person I've 
talked to who isn't working directly on Solaris LDAP development who has even 
noticed that LDAP user names are case-insensitive, much less complained.

> Btw, what was your plan for casesensitivity in filesystems?
>

Baby steps :-)

I do think that that's inevitable too, just not as soon as user names.  User names 
have more cross-platform impact, a more direct association to human names, and get 
typed by hand more often in many environments.

Any environment that interoperates with Windows will end up with case-insensitive 
file names, at least in data file systems. Case-insensitivity is already an option 
on ZFS, and a "mixed" mode is the default on our storage appliances.

> > UNIX is not the whole world, and the entire rest of the world is clear that 
> MARK, Mark, and mark
>
> > are the same person.
>
> With people, perhaps.  With people vs. service accounts perhaps not.  Perhaps I 
> have a user with
>
> a login name of 'sheila' but I also have a service account called 'SHEILA'.  I 
> suppose next you will
>
> be proposing to redefine the English language by saying that case is unimportant 
> when starting
>
> sentences, or when writing proper nouns vs nouns?  Be careful when you say "the 
> entire rest
>
> of the world", be sure you really know the entire rest of the world.  I don't 
> claim to, but I do have
>
> real examples of problems that DBIS is solving today.
>

I'd suggest that having a login name that duplicates a service account name, 
except for case, is asking for trouble.  Even in a relative bastion of UNIX like 
Oracle, we noticed that some of the corporate UIs present user names as all upper 
case.  Case sensitivity is really quite unnatural for humans.  There's no shortage 
of commercial systems that change the case of the left side of e-mail addresses, 
which will really mess you up if you're using the natural username@domain 
construction and your usernames are case-sensitive.  They're wrong, but they're 
common.  (And, importantly, almost nobody *notices* that they are wrong.)

I doubt we'd want to go too far off into the weeds on English semantics, but I'd 
argue that case *is* unimportant when starting sentences.  It helps to mark the 
beginning of the sentence, but does not otherwise affect the meaning of the word.  
When I say "Cars drive on roads" or "The cars are on the road", "Cars" and "cars" 
mean the same thing.  For proper nouns you have a point - Oracle and an oracle are 
two different things.  (Though even there, note the proper noun does not take an 
article.)  However, user names are always proper nouns.  Come to think of it, 
there's something interesting there.  "Mark" and "Bannister" are both proper 
nouns, yet "mark" and "bannister" are common nouns.  The only reason that we 
tolerate using "mark" and "bannister" as user names is that we internally convert 
them into their capitalized forms; treating them as common nouns as standard 
English would have us do wouldn't make any sense.

> > My key point here is that DBIS should specify what attribute should replace 
> it, what attribute
>
> > clients are expected to use to populate the pw_gecos field in struct passwd.
>
> draft-bannister-dbis-passwd provides a suggestion already in 2.1.3.1:
>
>    The posixUserAccount object class is auxiliary and must always be
>
>    associated with another structural class.  One such class is
>
>    inetOrgPerson [RFC2798].  If user accounts were given the
>
>    inetOrgPerson class, then displayName might be an appropriate value
>
>    for the dbisMapGecos attribute.
>
> Given that the gecos field can encode anything in any format, I didn't think I 
> could realistically
>
> do any better than provide a suggestion.
>

I think you could safely specify displayName as a MAY attribute, and let people 
use RFC 4876 mapping if for some reason they want to use something else.

Having two attribute-mapping mechanisms - RFC 4876 mapping and dbisMapGecos - 
seems bothersome.

> > >> posixGroup / posixGroupAccount
>
> > >>
>
> > >> X.521 groupOfNames seems like a more appropriate basis for the definition 
> of a group.
>
> > > But that doesn't allow for GID number.
>
> >
>
> > A subclass does.
>
> I have people telling me groupOfNames doesn't work well for them because it can 
> be a group
>
> of anything.  Extra LDAP searches are required to figure out what type of object 
> the members
>
> are.  That leads to a rather inefficient system.
>

There are two problems there:

1)  A group could contain anything, even when you want it to only contain one 
type.  Administrator error could lead to incorrect configurations.  In 
programming-ese, it's not type-safe.  One might hope that you could set up 
metadata limiting the types of objects that could be added to a group, like you 
can set up limits on the types of objects that can be put in a container, but I 
don't know if you can.  One hopes that your administration UIs will help here - if 
you're defining a group of users, the administration UI presumably knows that and 
only lets you add users.  At the same time, this flexibility enables nested 
groups, which can be very useful.
2)  You have to do "extra" searches to get any real information on the member.  
Yes, that's a very big problem.  The particular pain point is that getgrnam and 
getgrgid are defined to return a list of the members of the group, necessitating a 
search for *each* member. That gets pretty painful when a group has thousands of 
members.  I think the truly right answer there is to add new APIs that don't 
retrieve the members, and even to redefine the existing APIs to not retrieve the 
members, because there are almost no cases where it actually makes sense to 
retrieve the list of members of a UNIX group.  The standards provide some help in 
that there are hints in the UNIX standard that the list of members returned may 
not be complete.  Also:  Caching is your friend. Note also that the PADL version 
of nss_ldap has a "nss_getgrent_skipmembers" option that disables returning the 
list of members.

As long as we're talking about flaws in groupOfNames:  there's also the problem 
that "member" is a MUST attribute, and that makes empty groups problematic.  
Active Directory uses the same basic structure, but uses the "group" class instead 
of groupOfNames, and for "group" the "member" attribute is a MAY.  RFC2307bis-02 
replaces groupOfNames with groupOfMembers, again with "member" as a MAY.

(One might have hoped that you could have an attribute with a empty list of 
values, but X.501 does not allow that.)

> See previous reservations regarding groupOfNames.  Imagine trying to construct a 
> search
> operation to find just host members, or just user members.

Do note that the queries that you normally need are "is this host (or user) a 
member of this group" and "what groups is this user a member of".  It's hard to 
find cases where you really want to ask "what are the members of this group".  The 
"is this X a member" and "what groups is this X a member of" queries aren't bad at 
all with groupOfNames - you have to do a lookup on X to get its DN, but then you 
just do a natural (and efficient) search.

> > Having two names that differ only in case lead to different port numbers seems 
> like a
> > spectacularly bad idea.  If there's an organization that has somehow found 
> themselves
> > in such a mess then I'm very sorry for them
>
> <rant>
>
> Wait.  NIS permitted this.  If folk have done what NIS allowed them to do, and it
>
> fitted their working practice, then you can't blame them for that.  If you don't 
> like it
>
> and want to label it "a mess", that's fine you can do that, but I do not want to 
> leave
>
> people behind.  If you wish to call it a mess, then Sun Microsystems created the 
> mess,
>
> but it's infrastructure and we're stuck with it.  Imagine if the electronics 
> industry in America
>
> started selling devices with only English three-pin plugs 
> <https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiQzfjRs7rJAhUCKiYKHY6eCZoQFggiMAE&url=http%3A%2F%2Fwww.fastcodesign.com%2F3032807%2Fwhy-england-has-the-best-wall-sockets-on-earth&usg=AFQjCNEP4sremkvI56BoTb7D7rJhFaRbgg>, 
> citing that the original was a
>
> “bad design” and anyone who has found themselves in such a mess as to have
>
> incompatible wall sockets, well very sorry for them but that’s just tough luck.
>
> Right.  You’d cause an outcry.  Same thing applies here.  With NIS a particular
>
> working practice was absolutely fine. Now it isn’t.  And people are left to fix it
>
> themselves.  I think that’s very bad. (And for those who say “NIS is dead”, that’s
>
> absolutely not true, there are large organisations still using NIS and who haven’t
>
> yet migrated to LDAP, perhaps because the migration to LDAP is too hard for
>
> them in the present climate).
>
> </rant>
>

Well, kind of.  Yes, you were allowed to do it.  That doesn't necessarily mean 
that it was ever a good idea.

The structure of extension cords and power strips lets you daisy-chain them 
together to any length.  That doesn't mean that it's a good idea to do it, or that 
the fire marshal won't cite you on your next office inspection.

Also, remember that IANA, not NIS, is the authority on the definition of service 
names, and it defines them as case-insensitive.  There's a very good argument that 
NIS treating them in a case-sensitive way is a bug.