Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

On Mon, Oct 24, 2011 at 11:12 PM, Harry Coin <[email protected]> wrote:
> On 10/24/2011 10:56 PM, Nico Williams wrote:
>> You said GSS, now you say SASL.  I'm confused.
>
> That's because I live where applications maintained by lots of people who
> have firm ideas, such as yourself,  that don't comport with one another in
> small ways discovered by we folk who are supposed to stack all the bricks
> into something that delivers value reveal.   nslcd likes  Ldap, ldap likes
> sasl, sasl likes gssapi, gssapi likes kerberos.   If any one of those ice
> skaters falls down the whole chain is useless.  Oh, and ldap likes ssl.  Try
> to explain to nslcd whose /etc/passwd home directory is 'nonexistent' where
> 'user only' ldap.conf files should be found specifying the certificate
> locations for mutual authentication.  (all occurs before kerberos even
> enters the scene).

Why, again, does nslcd(8) need to be an NFS client?

>> No, no, you're confused.
>>
>> The service part of host-based service naming was *never* intended to
>> be a reference to Unix usernames or anything of the sort!  It was
>> intended to be a reference to service names from the IANA port
>> registry (i.e., what you expect to see in services(4)).
>
> Yes, I do know this.  Somehow the folk who craft these services are given to
> creating for them local user accounts with the same name for the
> implementing daemons to use.  ldap (okay, slapd, go figure).  nslcd,  nfs,
> etc.   We who don't author everything on our boxen have to go with the flow.

There's more than just the Solaris root/hostname one?  Can you list
them for me please?

>> If you want user/host-based naming then let's go for something like
>> <hostname>/<username>  or "user"/<username>/<hostname>  or something
>> along those lines, something unambiguously not conflicting with
>> host-based service naming!
>
> I do appreciate how it is you think I have the ability to implement those
> choices.   You are aware I trust that without the patches I wrote no
> principal with even one / in the list can write a file over a network share,
> much less the two you've written above?

It's difficult to communicate with you Harry.  It'd be easier if you
stopped treating me like I don't know what I'm talking about, and if
you stopped forgetting the things we've established already, and if
you wrote more succinctly.

Again:

1) NFS servers I know have their own aname2lname DB.  Does FreeBSD's
not have that?
2) I agree with you that we need an aname2lname DB in Heimdal, but you
ignore that I agree with you (is that because I don't agree with your
particular implementation?).
3) Clearly there's precedent for an aname2lname DB since a) MIT has
dormant (rotted) code for it, b) Solaris' and Linux's NFS servers have
gsscred DBs (which is what they call their aname2lname DB).

>>> Then we get into the whole 'taint' fiasco.    I just didn't want to patch
>>
>> One thing at a time please!
>
> For me it's all the same thing-- krb5, and what I need to do to not break
> anything that works, while adding what I need so I can secure the wire
> whether or not the principal has a / in it.

Well, I can't handle this many e-mails in a thread where all we do is
go back and forth.

If you want my help you'll need to communicate clearly and
respectfully, but more than anything clearly.  Alternatively I need
not participate in this thread any longer.  I don't own nor represent
Heimdal, and have no duty to it.

So for me, it's one thing at a time.  This will help me *later* go
back over e-mail and find the right ones when I'm writing code, tests,
etcetera.

>[...]
>> It's not deterministic.
>
> Well, in the real world lets just say that the upper bound of worst case
> compute time is so low the variability isn't something worth sweating over
> too much.   The only entries in /etc/k5login.d are going to be a couple of
> lines for each of the accounts without home directories in the /etc/passwd
> file.   Don't let lack of perfect stop you from accepting good.

Harry, a sorted text file will be faster and fully deterministic.
That is what I'll code-up for the default aname2lname plugin.  Can you
please tell us what's wrong with that?  Or better yet, don't.  You can
write your own plugin when I'm done.

You tell us how awful it is for administrators assuming that we have
not and do not administer systems.  I assure you that administrators
prefer deterministic behavior (for everything except RNGs that are
supposed to be true RNGs, of course).  I know because I've been an
administrator -- debugging non-deterministic behavior is not most
admins' idea of fun.

Admin: "I added an entry saying foo/bar.example maps to 'whatever'.
It used to work, but now it keeps mapping to 'something-else' and I
can't tell why"

Support engineer: "What is the output of ls -ld /etc/k5logind/, ls -lf
/etc/k5logind/, and grep foo/bar.example /etc/k5login.d/*?"

Admin: "Here's the output"

Support engineer: "Ah, I see you have two entries for foo/bar.example.
 The file named something-else is pretty old, so the dup must have
been around for a while before the behavior changed. Are you  using a
filesystem with a hash table implementation of directories?  Perhaps
at some point I bet the directory got re-created from an archive or
backup after enough changes in directory contents led to the dirent
order changing, or something like that -- maybe some admin futzed with
the files in there such that the dirent order changed.  Just remove
the duplicate entry."

That's not the kind of exchange I ever want to have, either as an
admin or as a developer or as a support engineer.  There's not enough
time in my life for that sort of conversation.

Nico
--