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

On Mon, 2011-10-24 at 22:36 -0500, Harry Coin wrote:
> > Yes, you *can* use principal names of that form.  The GSS-API doesn't
> > force you to.  And no GSS app that I know of forces you to use
> > *client* principal names of that form (with the exception I've
> > described before for root-equivalent access in the Solaris NFS
> > server).
> 
> You do keep mentioning this.  sasl client and sasl server just do insist 
> otherwise.

No, they don't.  They certainly expect you to use a GSS-API host-based
_service_ name, which results in a host-based Kerberos service principal
name like service/host.fqdn@REALM.  However, service names are not the
same as client names, and not the same as usernames.



> Then there's the whole 'reverse ip' thing where apps want 
> to confirm addresses and build principal names from service names and 
> the reverse dns.

Yeah; that's a behavior we more or less all wish would go away, and
we've been saying so in RFCs for many years now.  Unfortunately, too
many people find it convenient to type "ssh foo" and have something
figure out they meant the service host/[email protected],
where the DNS name foo.example.com is an alias for bar.example.com.
It's insecure but convenient, so people and code keep doing it.  But
that's not really relevant to the present discussion.



> I don't much want the service account user name to be 
> different than the service name than what appears before the / in the 
> principal name.

Ah, there we are.  _You_ want these things to be the same.  But there's
nothing in Kerberos and nothing in the GSS-API that says they have to be
the same.  That's something you've chosen to do, not something that SASL
or the GSS-API or any of us have forced on you.


> Sometimes I think the folk here forget somehow that 
> services generally own files, and it's a bad idea for them to all be 
> root.

Not at all.  It's a fine thing for services to run as their own user.
But there's nothing _anywhere_ that suggests that that user must have
the same name as the name of the service the process you.
 provides.

Would you run your web server as user "HTTP" ?  In uppercase?
That's a valid UNIX username, but I don't know anyone whose web servers
run as that user.

What username would you use for a mail server system that supports IMAP,
POP3, and managesieve?  Ours runs as user "cyrus", which is not the same
as the service name for any of those services.

What user should sshd run as?  Hint: it has to run as root, or it won't
work.  But the GSS-API service name is not "root"; it's "host".


> It's deterministic if the editor of the /etc/k5login.d directory doesn't 
> do anything that when they look at it would appear senseless anyhow.  

Nonsense.  It's entirely reasonable for the same principal to be
authorized to log in as more than one user.  But establishing such a
configuration using your patches and files in /etc/k5login.d causes the
result of krb5_aname2lname() to be nondeterministic.

Well, not quite.  It's deterministic, but not defined, and not easily
predictable.



> I'm sure someone could write a little test to validate that no principal 
> matches more than one username in /etc/k5login.d

Sure, you could write that.  But it would complain about valid
configurations in which one principal is permitted to log in as more
than one user.




>   (note it does not 
> check the user's home directories.   This adds functionality actually 
> since it's possible with this for admins to block the ability of a user 
> to affect the behavior of root enabled daemons reading ~/.k5login files.
> > By using a DB (Berkeley DB2, 3, 4, SQLite3, cdb, a flat text sorted
> > file, ...) you avoid the need for a cache, and you avoid the
> > non-deterministic behavior.
> 
> There's no point in bringing a tractor to a move a pea.

You and Nico seem to have different ideas of what a "database" is.  You
seem to think a database is some big heavyweight thing you don't want.
Whereas Nico includes things like /etc/passwd in his definition of
"database".  Probably because he's spent some time working on the name
service switch, and every nsswitch backend is a "database".

Nico's point is that your current design is nondeterministic; you can't
tell what the results of any arbitrary configuration will be.  A
well-ordered database, even a flat file read from beginning to end,
would eliminate this problem.  So, by the way, would always examining
the files in /etc/k5login.d in some specific order.

-- Jeff