All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simo Sorce <simo@redhat.com>
To: Cedric Blancher <cedric.blancher@gmail.com>
Cc: Steve Dickson <steved@redhat.com>, Jurjen Bokma <j.bokma@rug.nl>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	kerberos <kerberos@mit.edu>
Subject: Re: How to use NFS with multiple principals in different realms?
Date: Wed, 17 Sep 2014 17:31:04 -0400	[thread overview]
Message-ID: <20140917173104.4ea31d95@willson.usersys.redhat.com> (raw)
In-Reply-To: <CALXu0UcQ9YGTLnrjs5+AmVstAWmZ1QcNqOVeYyE-b_ktbfqvjw@mail.gmail.com>

On Wed, 17 Sep 2014 22:30:29 +0200
Cedric Blancher <cedric.blancher@gmail.com> wrote:

> On 17 September 2014 17:05, Simo Sorce <simo@redhat.com> wrote:
> > On Wed, 17 Sep 2014 13:20:19 +0200
> > Cedric Blancher <cedric.blancher@gmail.com> wrote:
> >
> >> What happens if there is no relation between KRB Realm names and
> >> FQDN/DNS? Can the NFS client find out which KRB Realm is used by
> >> the server?
> >
> > Depending on the environment you may have 1 or 2 ways.
> >
> > 1. add domain to realm mapping in the appropriate section in
> > krb5.conf on the client.
> > 2. allow the KDC to send back a referral (but not all clients will
> > ask their own KDC, some can do only 1).
> 
> But how can 1. help? Sure I can have my own krb5.conf but AFAIK
> rpc.gssd only looks at he system /etc/krb5.conf and not at any custom
> user defined location. Basically mount(8) would have to pass the
> location of the custom krb5.conf file to rpc.gssd to facilitate the
> mount, right?

A mount operation is a system-wide operation and requires privileges,
the system krb5.conf is what is used. Trusting a user provided
krb5.conf file for system level operations is not possible.

> I *think* we have a bigger problem here: Kerberos5 support in NFS
> appears to be designed around the philosophy of one realm per machine
> (one-to-rule-them'-all) and not that a single user or machine has
> mounts from many different realms, right?

wrong, the machine just need to 'know' about multiple realms and that
is done via domain_realm mappings, of course you can only have one
realm per dns domain.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

      reply	other threads:[~2014-09-17 21:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-04  9:04 How to use NFS with multiple principals in different realms? Cedric Blancher
2014-09-04  9:33 ` Jurjen Bokma
2014-09-04 11:25   ` Cedric Blancher
2014-09-04 12:32     ` Jurjen Bokma
2014-09-04 18:35       ` Simo Sorce
2014-09-10  0:31         ` Cedric Blancher
2014-09-10  2:18           ` Nordgren, Bryce L -FS
2014-09-10  6:47             ` Trond Myklebust
2014-09-10 13:06           ` Simo Sorce
2014-09-17 11:20             ` Cedric Blancher
2014-09-17 15:05               ` Simo Sorce
2014-09-17 20:30                 ` Cedric Blancher
2014-09-17 21:31                   ` Simo Sorce [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140917173104.4ea31d95@willson.usersys.redhat.com \
    --to=simo@redhat.com \
    --cc=cedric.blancher@gmail.com \
    --cc=j.bokma@rug.nl \
    --cc=kerberos@mit.edu \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steved@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.