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

On 10/24/2011 11:42 PM, Nico Williams wrote:
> 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.

So long as your plugin will report user names that kuserok will 
associate with the principal that gave rise to them, and it allows a / 
in the principal names, and does not require a user to have a home 
directory or .k5login file while being able to match more than one 
principal, and encodes all that in the text file protecting sections 
against those with insufficient privilege to read what how other 
principals might choose to do matching, I'm good with it.




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

Nico, when an array only less than a couple dozen entries you can throw 
a huge database engine at it to sort if you want to, but you don't have 
to.   I can't foresee the /etc/k5login.d having more than three or four 
lines for perhaps 4 or 5 usernames.  If that day comes, then improve the 
backend.  In the meanwhile the bloat is of dubious value, not to mention 
learning encoding arcana.  This implementation uses the familiar 
.k5login format.   Files can be protected as the the admins deem wise so 
unprivileged library users will still do the right thing without having 
to put all sorts of auth-restrictions on the text file.


>
> 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"
> \

How about 'run k5logind-check as a cron job'   slapd has a config 
checker, as do many.


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

Best to follow precedent and avoid it then.    Somehow this discussion 
has degenerated, I am sorry for that.
  It's not my agenda to argue, I do wish you all the best and thank you 
for these efforts to date.

> Nico
> --
>