From: Andreas Dilger <adilger@sun.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] GSS cross-realm on MDT -> OST
Date: Fri, 11 Jul 2008 15:32:07 -0600 [thread overview]
Message-ID: <20080711213207.GK6239@webber.adilger.int> (raw)
In-Reply-To: <20080709211013.GA8132@lanczos.q-leap.de>
On Jul 09, 2008 23:10 +0200, Bernd Schubert wrote:
> On Wed, Jul 09, 2008 at 02:29:38PM -0600, Andreas Dilger wrote:
> > Please see bug 15827 with some details of the problem.
> >
> > For the non-kerberos case having administrator action at the MGS is
> > the most secure. Enabling a shared secret key passed to mkfs.lustre
> > like "--mgs-key e85021aee637f7250e482a9a5b23cb0d" sent from the
> > MDT/OST to the MGS at first connect time at least provides some
> > restriction on adding new devices to the filesystem.
>
> Hmm, is a secret key really neccessary, for me this sounds a bit like
> security by obscurity. Wouldn't it be better to to have a two way
> MDT/OST registration?
>
> 1.) As it is, simply mount the filesystem on the MDT/OST. But this will
> put this filesystem into a registered, but unconfirmed state on the MGS.
>
> 2.) Introduce a lctl command for the MGS to list all
> registered-but-unconfirmed systems. And another command to confirm the
> registration.
Yes, this is defintely the minimum requirement, and it should be the
default behaviour. For the case when completely automated configuration
is needed (e.g. during automated regression testing) then having the
--mgs-key mount option would still prevent "random" OSTs from joining the
filesystem (as in bug 15827).
> On on the other hand, this approach might conflict with the writeconf concept.
No, I think 2-step authentication is the most secure, but there needs
to some way to circumvent it, only if the MGS allows it of course. If
the MGS is compromised then all bets are off...
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
next prev parent reply other threads:[~2008-07-11 21:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <48728D97.1020704@psc.edu>
2008-07-08 17:27 ` [Lustre-devel] GSS cross-realm on MDT -> OST Eric Mei
2008-07-08 17:43 ` Peter Braam
2008-07-08 18:41 ` Benjamin Bennett
2008-07-08 19:39 ` Peter Braam
2008-07-08 20:38 ` Benjamin Bennett
2008-07-09 14:31 ` Peter Braam
2008-07-09 17:25 ` Eric Mei
2008-07-09 20:07 ` Benjamin Bennett
2008-07-10 16:45 ` Eric Mei
2008-07-09 20:29 ` Andreas Dilger
2008-07-09 21:10 ` Bernd Schubert
2008-07-11 21:32 ` Andreas Dilger [this message]
2008-07-08 19:21 ` Josephine Palencia
2008-07-08 20:38 ` Andreas Dilger
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=20080711213207.GK6239@webber.adilger.int \
--to=adilger@sun.com \
--cc=lustre-devel@lists.lustre.org \
/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.