Subject: [nfsv4] NFSv4 WG Last Call for pNFS Flexible File Layout - closes on Jan 20th

From: Spencer Shepler <[email-masked]>
Date: Mon, 5 Jan 2015 23:14:08 +0000

Hi.  I am announcing the start of a Last Call for the Parallel NFS (pNFS) Flexible File Layout (draft-ietf-nfsv4-flex-files-04.txt) I-D.

Please take time and review this document and provide feedback.  I believe this document is of particular interest to the WG and there has been productive discussion in the past on the content.

The Last Call will end on January 20th.

Spencer

---

From: Olga Kornievskaia <[email-masked]>
Date: Thu, 15 Jan 2015 11:39:56 -0500

Can somebody provide more explanation/comment on "ffds_auth" field?

>From reading the spec, this field is only present for loosely coupled
storage devices. But what exactly is it? If it's a GSS flavor rcp, is
it a gss_context itself? If so, what prevents an eavesdropper from
getting it and using it or for denial-of-service somebody modifying
it. Should there be a requirement that the reply must be protected
with gss_privacy? If ffds_auth is only AUTH_SYS uid/gid pair why not
clearly state it? Can we not call it "auth" and instead have two
integers for uid/gid and it will not confuse the reader that it's
anything else. Lastly, if we want to distribute capabilities why not
use gssv3 for this?

In section 2.2 there is a statement: "As part of the layout, the
client is provided with the rpc credentials to be used (see ffm_auth
in Section 5.1) to access the data file." As far as I can see there is
nothing named "fm_auth" in Section 5.1. Should it be "ffds_auth"?

Thank you.

On Mon, Jan 5, 2015 at 6:14 PM, Spencer Shepler <[email-masked]> wrote:
>
>
> Hi.  I am announcing the start of a Last Call for the Parallel NFS (pNFS)
> Flexible File Layout (draft-ietf-nfsv4-flex-files-04.txt) I-D.
>
>
>
> Please take time and review this document and provide feedback.  I believe
> this document is of particular interest to the WG and there has been
> productive discussion in the past on the content.
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Tom Haynes <[email-masked]>
Date: Thu, 15 Jan 2015 09:26:52 -0800

> On Jan 15, 2015, at 8:39 AM, Olga Kornievskaia <[email-masked]> wrote:
> 
> storage devices. But what exactly is it?

The patches for the Linux client implementation are available. :-)

Look at ff_layout_parse_auth() for one implementation.

> If it's a GSS flavor rcp, is
> it.

Section 2.2 addresses this:

  This
   security method, when using weak auth flavors such as AUTH_SYS,
   provides a practical model to enforce access control and fence off
   cooperative clients, but it can not protect against malicious
   clients; hence it provides a level of security equivalent to NFSv3.

BTW - thanks, this points out that this line in that same paragraph is wrong:

   As part of the layout, the client is provided with
   the rpc credentials to be used (see ffm_auth in Section 5.1) to
   access the data file.

s/ffm_auth/ffds_auth/

> Should there be a requirement that the reply must be protected
> clearly state it?

I’m surprised this isn’t clearer, but I’m afraid that means I am too close to it.

Looking at the code which tests the XDR extracted from the file, we see:

                echo "%#include <rpc/auth.h>" > auth.x ; \
                echo "%typedef struct opaque_auth opaque_auth;" >> auth.x ; \

Which for Linux is:

/*
 * Authentication info.  Opaque to client.
 */
struct opaque_auth {
        enum_t  oa_flavor;              /* flavor of auth */
        caddr_t oa_base;                /* address of more auth stuff */
        u_int   oa_length;              /* not to exceed MAX_AUTH_BYTES */
};

I now have an AI to provide a proper reference to opaque_auth (and the XDR).

This should answer your question.

> Can we not call it "auth" and instead have two
> anything else.

See above

> Lastly, if we want to distribute capabilities why not
> use gssv3 for this?

Yes, we should do that - but I didn’t see the deliverables lining up here.

I.e., my thought was that this could still be delivered at a later date. Will opaque_auth
handle this?

> nothing named "fm_auth" in Section 5.1. Should it be "ffds_auth”?

Yes. :-)

> Thank you.

Thanks for the comments!

> 
> 
> On Mon, Jan 5, 2015 at 6:14 PM, Spencer Shepler <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>

---

From: Olga Kornievskaia <[email-masked]>
Date: Thu, 15 Jan 2015 13:13:10 -0500

>    clients; hence it provides a level of security equivalent to NFSv3.

I'm sorry I don't think this is clear. It says if auth_flavor is
chosen to be AUTH_SYS then "....". So what if auth_flavor is not
AUTH_SYS?

I would like for this to be clearly be stated that auth_flavor MUST be
AUTH_SYS. If it's not AUTH_SYS, I strongly disagree with passing
security context in the clear.

> I.e., my thought was that this could still be delivered at a later date.

If gssv3 is used, then there is no need for the ffds_auth field in the
structure. So leaving it for later seems wrong as it'll imply a change
of the proposed structure.

---

From: Tom Haynes <[email-masked]>
Date: Thu, 15 Jan 2015 10:29:08 -0800

> On Jan 15, 2015, at 10:13 AM, Olga Kornievskaia <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Given that we want to allow for kerberized access in the future, what would
you plop down into the XDR instead of opaque_auth?

I.e., I’m perfectly fine with making your suggested change, but that will not
fly when we try to push this document past the WG.

---

From: Olga Kornievskaia <[email-masked]>
Date: Thu, 15 Jan 2015 14:05:00 -0500

> fly when we try to push this document past the WG.

I'm just stating my opinion which is that having this as is should not
pass the WG either.

The only solution I currently see (not to say there isn't something
else there) is use of gssv3 authorization assertions and not have any
opaque_auth in this document at all. Nothing else is secure because we
need to prevent somebody from misusing the capability (i.e. ffds_auth)
returned by the server. The responsibility of this spec would be to
specify what goes into the assertion and how it's used and verified by
the data servers.

I'd like to go back to my original question about what does it mean
for that auth_flavor to be GSS. Let me set my concern about passing
this capability in the clear aside. What did you envision here? I'm
having a hard time understanding what it means. Were you planning on
passing back gss_context (i.e.., keys)? I see that with AUTH_SYS you
can do a SETATTR for the uid. What would you do for the GSS context?

---

From: Tom Haynes <[email-masked]>
Date: Thu, 15 Jan 2015 13:03:47 -0800

> On Jan 15, 2015, at 11:05 AM, Olga Kornievskaia <[email-masked]> wrote:
> 
> opaque_auth in this document at all.

But mandating gssv3 is a non-starter in that we can not retrofit all existing storage devices out there.

> Nothing else is secure because we
> passing back gss_context (i.e.., keys)?

As far as I can tell, the original intent was to take the credential that would be used in
the RPC layer and present it to the client.  It would then send that off to the storage device.

Does this look like man in the middle for krb5? Sure.

1) Half-baked solution:

Send back the UID and GID(s) needed to the client. It then has to contact the KDC to get
tickets for them. It can then present these to the storage device.

2) Or we can state that with loosely-coupled deployments, there is no security other than AUTH_SYS.
If the site needs stronger security, there has to be a tightly-coupled system in which fencing is
not done by UID/GID and mode bits. Both the metadata and data portion of the file have the
same owner/group and thus the credentials presented by the client (whatever flavor) are
sufficient for the storage device.

> I see that with AUTH_SYS you

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 15 Jan 2015 22:00:07 -0500 (EST)

> existing storage devices out there.

But they could be retrofitted with any other new thing we come up with
here?  I'm not sure I see how this argument is supposed to work.

> Send back the UID and GID(s) needed to the client. It then has to
> contact the KDC to get tickets for them. It can then present these to
> the storage device.

I only got a chance to skim the document, but it looks like the metadata
server could use the services for user (S4U) kerberos extensions from
Microsoft [MS-SFU] to get an actual ticket and act on behalf of the real
client.  The client could then auth to the storage device with its normal
credentials (i.e., the user's kerberos ticket).  The metadata server would
need to be marked as having elevated privilege of one form or another on
the KDC, of course.

> 2) Or we can state that with loosely-coupled deployments, there is no
> security other than AUTH_SYS. If the site needs stronger security, there
> has to be a tightly-coupled system in which fencing is not done by
> UID/GID and mode bits. Both the metadata and data portion of the file
> have the same owner/group and thus the credentials presented by the
> client (whatever flavor) are sufficient for the storage device.

I'm unconvinced that there is not a way to do security other than AUTH_SYS
for loosely-coupled deployments.  It may not be worth spending the time to
figure out what such a thing would look like, though.

-Ben

[MS-SFU] http://msdn.microsoft.com/en-us/library/cc246071.aspx

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 15 Jan 2015 23:06:18 -0500

> need to be marked as having elevated privilege of one form or another on

You're missing the point. It is trivial to give the MDS elevated
privileges on the DS itself: just turn off root squashing, and the MDS
can do whatever it wants on behalf of the client by switching to using
the root identity.

The problem to be solved is about giving it the ability to _fence_off_
the client so that the latter can no longer access the file on the DS
when it doesn't hold a layout.
IOW: it is about revoking one particular client's ability to access
one particular file on the DS.

Trond

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 15 Jan 2015 23:11:32 -0500 (EST)

> You're missing the point. It is trivial to give the MDS elevated

My apologies.

Sorry for the noise,

Ben

---

From: David Noveck <[email-masked]>
Date: Fri, 16 Jan 2015 05:16:21 -0500

> But mandating gssv3 is a non-starter in that we can not retrofit all
existing storage devices out there.

Yes.

> 2) Or we can state that with loosely-coupled deployments, there is no
security other than AUTH_SYS.

As I read the last paragraph of section 15 , it says "realistically, loose
coupling is never going to be Kerberized."

The question is about changing it to say "Loose coupling is NEVER going to
be Kerberized",  I sense there is
some worry about the IESG's reaction.  Still, I can't see that AUTH_SYS
access to legacy NFSv3 data storage devices
is any worse than access to block storage devices.

Note that if you give up on the particular loose coupling model currently
in the document, it doesn't mean that
you have to go all the way to a tight coupling model with global stateid
support.  If you don't need to support
NFSv3, you could still hand out stateids for the client to use (as in loose
coupling) and do revocation by
stateid invalidation, instead of ownership changes.

On Thu, Jan 15, 2015 at 4:03 PM, Tom Haynes <[email-masked]>
wrote:

> >> I.e., I’m perfectly fine with making your suggested change, but that
> will
> >> not
> security other than AUTH_SYS.

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 16 Jan 2015 16:03:42 +0000

> On Jan 16, 2015, at 5:16 AM, David Noveck <[email-masked]> wrote:
> 
> As I read the last paragraph of section 15 , it says "realistically, loose coupling is never going to be Kerberized."
> 
> The question is about changing it to say "Loose coupling is NEVER going to be Kerberized",  I sense there is
> some worry about the IESG's reaction.

So why not mandate gssv3 for Kerberized loose coupling, and not for AUTH_SYS? You loose nothing, and there is a way forward.

>  Still, I can't see that AUTH_SYS access to legacy NFSv3 data storage devices

Which, as RFC 5663 states, 

   "It is the
   responsibility of those administering and deploying pNFS with a
   block/volume storage access protocol to ensure that appropriate
   protection is provided to that protocol (physical security is a
   common means for protocols not based on IP).  In environments where
   the security requirements for the storage protocol cannot be met,
   pNFS block/volume storage layouts SHOULD NOT be used.”

We want a way out of this requirement, e.g. the ability to eventually use Kerberos.

—>Andy

> 
> Note that if you give up on the particular loose coupling model currently in the document, it doesn't mean that
> you have to go all the way to a tight coupling model with global stateid support.  If you don't need to support 
> NFSv3, you could still hand out stateids for the client to use (as in loose coupling) and do revocation by 
> On Thu, Jan 15, 2015 at 4:03 PM, Tom Haynes <[email-masked]> wrote:
>

---

From: Tom Haynes <[email-masked]>
Date: Fri, 16 Jan 2015 09:24:28 -0800

> On Jan 16, 2015, at 8:03 AM, Adamson, Andy <[email-masked]> wrote:
> 
>> 
>> On Jan 16, 2015, at 5:16 AM, David Noveck <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> 

I actually want to go back to one of Olga’s proposals, which was to send the UID and GID as fields.

Actually, I would propose handling them as owner and owner_group, they could either be stringified
UID or GID, or user@dns_domain.

In that scenario, can the client authenticate to the KDC with that user (or group) string?

I.e., as part of the deployment of a kerberized flex file server, the admins would most likely reserve a
range of UIDs to allow client access to files on the DSes. As needed, the clients would authenticate
as these users.

And if that is not palatable, what language do we need in the spec to allow gssv3 to proceed here?

---

From: Olga Kornievskaia <[email-masked]>
Date: Fri, 16 Jan 2015 13:24:15 -0500

> And if that is not palatable, what language do we need in the spec to allow

I'd like actually question the usefulness of sending uid/gid back to
the client. Normally, in a file system, it has been the case that a
client can find out who has access to the file by querying its
attributes, acls. The assumption is that the client access it with
whatever identity is has and the access will either be granted or
disallowed. Why move away from this model.

I really don't see a good practical (secure) case for it. Say Alice is
accessing a file and doing a getlayout and with this proposal it will
get a reply saying "please access it as Bob". Now in a Kerberos world,
what likelihood is Alice actually also Bob.

Actually why add extra fields at all. Why not have a getlayout
followed by getattr that returns back the information with the
uid/gid?

---

From: David Noveck <[email-masked]>
Date: Fri, 16 Jan 2015 13:40:34 -0500

> We want a way out of this requirement, e.g. the ability to eventually use
Kerberos.

The most obvious way out of it is to use NFSv4 data servers.  Is there any
reason to make
a big effort to support this form of kerberized access for NFSv3 data
servers.?

On Fri, Jan 16, 2015 at 11:03 AM, Adamson, Andy <[email-masked]>
wrote:

> > As I read the last paragraph of section 15 , it says "realistically,
> loose coupling is never going to be Kerberized."
> >
> So why not mandate gssv3 for Kerberized loose coupling, and not for
> AUTH_SYS? You loose nothing, and there is a way forward.
>
> > Note that if you give up on the particular loose coupling model
> currently in the document, it doesn't mean that
> contact the KDC to get

---

From: Tom Haynes <[email-masked]>
Date: Fri, 16 Jan 2015 11:11:33 -0800

> On Jan 16, 2015, at 10:40 AM, David Noveck <[email-masked]> wrote:
> 
> The most obvious way out of it is to use NFSv4 data servers.  Is there any reason to make
> a big effort to support this form of kerberized access for NFSv3 data servers.?

Using NFSv4 does not solve the issue, it has to be a tightly coupled system. I.e., the same
owner and owner_group on both the metadata and data portions of the file. And then the
DS and MDS can validate/invalidate stateids in the control protocol.

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 16 Jan 2015 19:07:17 +0000

> On Jan 16, 2015, at 1:40 PM, David Noveck <[email-masked]> wrote:
> 
> The most obvious way out of it is to use NFSv4 data servers.  

I don’t know what you mean. NFSv3 and NFSv4.x data servers all use the same kerberos implementation - e.g. RPCSEC_GSS.

> Is there any reason to make
> On Fri, Jan 16, 2015 at 11:03 AM, Adamson, Andy <[email-masked]> wrote:
>

---

From: Tom Haynes <[email-masked]>
Date: Fri, 16 Jan 2015 11:21:24 -0800

> On Jan 16, 2015, at 10:24 AM, Olga Kornievskaia <[email-masked]> wrote:
> 

Because of the need to fence off access on the DS from the client. Either
there needs to exist a control protocol (tightly-coupled) or we need some
form of communication via the NFS protocol (loosely-coupled).

The mode bits are set on the data portion of the file such that the owner
of the file has read/write access and the group has read access. To fence
off clients, the owner and/or group need to be modified.

To allow access at all, the owner and owner_group must be sent to the
client. I do agree that we should not do that as a red, but call out them
out explicitly.

> what likelihood is Alice actually also Bob.

And I agree that we should not do these shenanigans in a Kerberos world.

If either you or Andy want to show how we can do it with gssv3, I’m happy
to add that to the layout spec.

Otherwise, I’m just as happy to state that if you want Kerberos, then it
has to be a tightly-coupled approach.

> followed by getattr that returns back the information with the

Because that requires adding a new attribute, which is not allowed at
this time for NFSv4.1.

And note that the user and/or group could be different on the different DSes
providing the mirrors. I.e., this is not a file property, but a device info property.

---

From: Olga Kornievskaia <[email-masked]>
Date: Fri, 16 Jan 2015 15:41:33 -0500

> client. I do agree that we should not do that as a red, but call out them

That doesn't really answer the question why there is need to know
before hand of who can read the file. If I'm the owner or in the group
and created the file, I can access the file. Fencing can still be done
via mode bits. I don't need to know if I can access the file or not.
If I'm not the owner (or in the group), then I probably don't have the
credentials to access it. So why bother sending me that information.

> providing the mirrors. I.e., this is not a file property, but a device info property.

I'm not going to argue that gssv3 is the only solution. Actually, I'm
more in favor off sending back identify information and letting the
client acquire the necessary credentials (note: I'm still unsure how
practical it is to be both Alice and Bob). I'm against calling
identify information "an auth" as a generic term. I realized that it
's "a cred" in NFSv3 world but we all know that it's insecure. Perhaps
uid/gid is too restrictive and it needs to handle the case where
identity is represented as string, nfs4_user@nfs4_domain thus stepping
into the gss world.

---

From: Olga Kornievskaia <[email-masked]>
Date: Fri, 16 Jan 2015 15:45:07 -0500

> credentials to access it. So why bother sending me that information.

I forgot to add:

I don't buy the practically of the approach that changes ownership of
the same (mirrored) files on different storage devices. I can see why
maybe it won't be the same uid/gid but isn't why we created a generic
string representation that can locally be mapped into the local
representation.

---

From: Tom Haynes <[email-masked]>
Date: Fri, 16 Jan 2015 13:42:13 -0800

> On Jan 16, 2015, at 12:41 PM, Olga Kornievskaia <[email-masked]> wrote:
> 
> via mode bits.

No, it cannot. Look at Section 4.4 of RFC 1813:

   On a local file system, a user can open
   a file and then change the permissions so that no one is
   allowed to touch it, but will still be able to write to the
   file because it is open. On a remote file system, by
   contrast, the write would fail. To get around this problem,
   the server's permission checking algorithm should allow the
   owner of a file to access it regardless of the permission
   setting. This is needed in a practical NFS version 3 protocol
   server implementation, but it does depart from correct local
   file system semantics.
I.e., you cannot fence off the owner with mode bits in NFSv3.

This also applies to the paging discussion in the next paragraph.

> I don't need to know if I can access the file or not.

Yes, my earlier proposal today was the stringified owner and owner_group.

---

From: Tom Haynes <[email-masked]>
Date: Fri, 16 Jan 2015 13:45:20 -0800

> On Jan 16, 2015, at 12:45 PM, Olga Kornievskaia <[email-masked]> wrote:
> 
> I forgot to add:
> 

The issue here is that the storage device does not understand the generic
string notation. And thus the MDS, storage device, and client have to agree
on the value stored on the storage device.

In such a scenario, the server would send the UID in string form.

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 16 Jan 2015 22:32:44 +0000

Hi Tom

Here are my review comments so far.

1) NIT: 
There are several places you use NFSv4.1 where NFSv4.2 also applies

Abstract
"The metadata file access is handled via Network File System version 4 (NFSv4) minor version 1
   (NFSv4.1)”

Introduction:
"To provide a global state model equivalent to that of the Files
   Layout Type, a back-end control protocol MAY be implemented between
   the metadata server and NFSv4.1 storage devices.”

Definitions:
File Layout Type:  is a Layout Type in which the storage devices are
      accessed via the NFSv4.1 protocol.  It is defined in Section 13 of
      [RFC5661].

Both pNFS MDS and DS can be NFS4.2

2) NIT:
Definition:  "loose coupling:  is when the metadata server and the storage device do not have a control protocol present.”

and then in the Coupling of Storage Devices:  "With a loose coupling, the only control protocol might be a version of NFS….”

How about changing the definition to:

""loose coupling:  is when the metadata server and the storage devices
      do not have a control protocol other than a version of NFS.”

3) Security Models

 "   With loosely coupled storage devices, the metadata server uses
   synthetic uids and gids.."

What is a synthetic uid, gid? How is it chosen? Is there a synthetic uid/gid pair per client per storage device? More information please.

 "Note: it is recommended to implement common access control methods at the
   storage device filesystem exports level to allow only the metadata
   server root (super user) access to the storage device"

Don't you mean "access to the portion of the NFS server export used as a loosely coupled storage device" - after all, the storage device can also act as a standalone NFS server for all non-flexfile exports. I think you need to make it _really_ clear exactly what is required, not just the easy case when the NFS server is only a part of the loosely coupled system.

 "This
   security method, when using weak auth flavors such as AUTH_SYS,
   provides a practical model to enforce access control and fence off
   cooperative clients, but it can not protect against malicious
   clients; hence it provides a level of security equivalent to NFSv3."

If I understand the design correctly, I disagree with the above.

From what I can tell, you are proposing to have each client use each loosely coupled storage device’s synthetic uid/gid pair (returned by layoutget) to access _all_ files for _all_ users.  (note that you need to describe all this a bit better).

This method of using synthetic uid/gid on all data files, and a SETATTR to fence provides a level of security equivilent to AUTH_SYS no matter what NFS version you use, and in fact, no matter if you use Kerberos or not - because you are depending on non-malicious clients, _not_ on a secure protocol.

For example, a malicious client can take the synthetic uid/gid and access _any_ _file_ on the DS, whether it OPENed the file or not, whether the user has acces to the file or not. The use of Kerberos would not change this, as the malicious client can send the non-approved I/O with the synthetic uid/gid over a Kerberos channel and get access. So the _only_ security that the loosley coupled design provides is to trust the client not to be bad.  This looks to me to be just like the blocklayout protocol, and this lack of security needs to be clearly stated.

This is more truthful:

 "This
   security method provides a practical model to enforce access control and fence off
   cooperative clients, but it can not protect against malicious
   clients; hence it provides a level of security equivalent to AUTH_SYS”

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 16 Jan 2015 18:51:03 -0500

> From what I can tell, you are proposing to have each client use each loosely coupled storage device’s synthetic uid/gid pair (returned by layoutget) to access _all_ files for _all_ users.  (note th…

No. That is not what is being proposed or implied.

> For example, a malicious client can take the synthetic uid/gid and access _any_ _file_ on the DS, whether it OPENed the file or not, whether the user has acces to the file or not. The

How would it do this? Standard NFS permissions rules apply here; there
is no need to give the synthetic uid/gid any special root privileges
or allow it to access any files on the DS other than the one that the
layout targets.

use of Kerberos would not change this, as the malicious client can
send the non-approved I/O with the synthetic uid/gid over a Kerberos
channel and get access. So the _only_ security that the loosley
coupled design provides is to trust the client not to be bad.  This
looks to me to be just like the blocklayout protocol, and this lack of
security needs to be clearly stated.

How does kerberos or any other security flavour help you if the NFS
client itself is compromised?

That isn't a problem that is specific to flex files. All kerberos can
help you do is secure your _communications_ channel (provided that you
use integrity checking or stronger). If I have root privileges on your
kernel, you're SOL no matter what security mechanism you try to
implement.

>    clients; hence it provides a level of security equivalent to AUTH_SYS”

I don't see how "cannot protect against malicious clients" implies
"level of security equivalent to AUTH_SYS". That statement would imply
that all security mechanisms are "equivalent to AUTH_SYS".

Cheers
  Trond

---

From: Trond Myklebust <[email-masked]>
Date: Sat, 17 Jan 2015 13:12:05 -0500

Hi Ben,

>> You're missing the point. It is trivial to give the MDS elevated

I didn't intend to shut you up, just to clarify what the goals are.
I'm hoping the above idea can work, but it would have to work to
authenticate the client to a DS.

Assume that MDS.DOMAIN is a kdc that has a trust relationship with
CORP.DOMAIN. Is it possible to use S4U to allow an authenticated
[email-masked] on the NFS client to obtain a ticket for the
principal "myfilelayout/[email-masked]" and set up a
RPCSEC_GSS/krb5 session to a DS as that principal?

Cheers
  Trond

---

From: Tom Haynes <[email-masked]>
Date: Mon, 19 Jan 2015 10:38:10 -0800

Hi Andy,

Thanks for the review and comments.

> On Jan 16, 2015, at 2:32 PM, Adamson, Andy <[email-masked]> wrote:
> 
> Hi Tom
> 

Yes, I should state it as NFSv4.1+.

>      do not have a control protocol other than a version of NFS.”

In the context of this draft, NFS is the available control protocol. But, the term is more generic.

> What is a synthetic uid, gid? How is it chosen? Is there a synthetic uid/gid pair per client per storage device? More information please.

Ack, I get your point.

Basically, we envision that there is a range of uids configured for the MDS to use. When the MDS wants to grant permission to a client,
it assigns and sends the uid/gid to the client. (Note that the assignment may only occur the first time permission is granted.) When the
fencing occurs, the uid is changed.

I can write some notes here, but the way uids and gids are chosen is strictly an implementation choice.

---

From: Tom Haynes <[email-masked]>
Date: Mon, 19 Jan 2015 10:47:44 -0800

> On Jan 16, 2015, at 3:51 PM, Trond Myklebust <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Tom
>> 

And I’ll word it better.

> that all security mechanisms are "equivalent to AUTH_SYS”.

Another way to state this is that given the data protocol will most likely
be NFSv3 and there should be an export policy in place to allow the
clients access, then the data files on the storage devices will most likely
be visible in some name space. The client can mount that namespace 
and troll through it. Whether the names are sane (i.e., same directory
and file names as on the MDS) or insane (i.e., hashed values or UUIDs),
the client can still find things and spoof the assigned UID/GID values.

That spoofing is a malicious client. It is the same for all exports that are
done via AUTH_SYS.

If however the export is kerberized, then the client is prevented from accessing
files for users that it cannot generate tickets for.