From: John Spray <john.spray@redhat.com>
To: Sage Weil <sweil@redhat.com>, ceph-devel@vger.kernel.org
Cc: nishtha3rai@gmail.com
Subject: Re: MDS auth caps for cephfs
Date: Fri, 22 May 2015 10:28:48 +0100 [thread overview]
Message-ID: <555EF6D0.5000903@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1505201651260.23818@cobra.newdream.net>
On 21/05/2015 01:14, Sage Weil wrote:
> Looking at the MDSAuthCaps again, I think there are a few things we might
> need to clean up first. The way it is currently structured, the idea is
> that you have an array of grants (MDSCapGrant). For any operation, you'd
> look at each grant until one that says what you're trying to do is okay.
> If non match, you fail. (i.e., they're additive only.)
>
> Each MDSCapGrant has a 'spec' and a 'match'. The 'match' is a check
> to see if the current grant applies to a given operation, and the 'spec'
> says what you're allowed to do.
>
> Currently MDSCapMatch is just
>
> int uid; // Require UID to be equal to this, if !=MDS_AUTH_UID_ANY
> std::string path; // Require path to be child of this (may be "/" for any)
>
> I think path is clearly right. UID I'm not sure makes sense here... I'm
> inclined to ignore it (instead of removing it) until we decide
> how to restrict a mount to be a single user.
>
> The spec is
>
> bool read;
> bool write;
> bool any;
>
> I'm not quite sure what 'any' means, but read/write are pretty clear.
Ah, I added that when implementing 'tell' -- 'any' is checked when
handling incoming MCommand in MDS, so it's effectively the admin permission.
> The root_squash option clearly belongs in spec, and Nistha's first patch
> adds it there. What about the other NFS options.. should be mirror those
> too?
>
> root_squash
> Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does
> not apply to any other uids or gids that might be equally sensitive, such
> as user bin or group staff.
> no_root_squash
> Turn off root squashing. This option is mainly useful for diskless
> clients.
> all_squash
> Map all uids and gids to the anonymous user. Useful for NFS-exported
> public FTP directories, news spool directories, etc. The opposite option
> is no_all_squash, which is the default setting.
> anonuid and anongid
> These options explicitly set the uid and gid of the anonymous account.
> This option is primarily useful for PC/NFS clients, where you might want
> all requests appear to be from one user. As an example, consider the
> export entry for /home/joe in the example section below, which maps all
> requests to uid 150 (which is supposedly that of user joe).
Yes, I think we should. Part of me wants to say that people who want
NFS-like behaviour should be using NFS gateways. However, these are all
probably straightforward enough to implement that it's worth maintaining
them in cephfs too.
We probably need to mirror these in our mount options too, so that e.g.
someone with an admin key can still enable root_squash at will, rather
than having to craft an authentication token with the desired behaviour.
> We could also do an all_squash bool at the same time (or a flags field for
> more efficient encoding), and anonuid/gid so that we don't hard-code
> 65534.
>
> In order to add these to the grammer, I suspect we should go back to
> root_squash (not squash_root), and add an 'optoins' tag. e.g.,
>
> allow path /foo rw options no_root_squash anonuid=123 anongid=123
>
> (having them live next to rw was breaking the spirit parser, bah).
Looks good to me.
John
next prev parent reply other threads:[~2015-05-22 9:28 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-21 0:14 MDS auth caps for cephfs Sage Weil
2015-05-22 9:28 ` John Spray [this message]
2015-05-22 21:35 ` Sage Weil
2015-05-22 22:02 ` Gregory Farnum
2015-05-22 22:18 ` Sage Weil
2015-05-22 22:38 ` Gregory Farnum
2015-05-22 22:52 ` Sage Weil
2015-05-26 14:26 ` Gregory Farnum
2015-05-26 16:28 ` Sage Weil
2015-05-26 21:26 ` Sage Weil
2015-05-26 21:53 ` Gregory Farnum
2015-05-26 22:17 ` Sage Weil
2015-05-26 22:50 ` Gregory Farnum
2015-05-26 23:12 ` Sage Weil
2015-05-26 23:32 ` Gregory Farnum
2015-05-27 21:44 ` Sage Weil
2015-05-27 22:03 ` Gregory Farnum
2015-05-27 22:21 ` Sage Weil
2015-05-27 22:40 ` Gregory Farnum
2015-05-27 23:07 ` Sage Weil
2015-05-27 23:18 ` Gregory Farnum
2015-05-27 23:59 ` Sage Weil
2015-05-28 0:11 ` Gregory Farnum
2015-05-28 0:37 ` Sage Weil
2015-05-28 0:42 ` Gregory Farnum
2015-05-28 16:20 ` Robert LeBlanc
2015-05-28 16:42 ` Gregory Farnum
2015-05-28 17:02 ` Sage Weil
2015-05-28 17:21 ` Robert LeBlanc
2015-05-28 17:32 ` Sage Weil
2015-05-28 18:29 ` Robert LeBlanc
2015-06-01 19:39 ` Sage Weil
2015-06-02 23:40 ` Gregory Farnum
2015-05-28 17:06 ` Robert LeBlanc
2015-05-26 12:56 ` John Spray
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=555EF6D0.5000903@redhat.com \
--to=john.spray@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=nishtha3rai@gmail.com \
--cc=sweil@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.