headers
Nicolas Williams | 1 Mar 2003 07:34
Picon

Re: draft-eisler-nfsv4-ccm-00.txt

On Fri, Feb 28, 2003 at 10:42:25AM -0500, Dai_Peng <at> emc.com wrote:
> This is prevented by ensuring the binding between the CCM context and the
> secure channel is legit, as outlined in 2a. Additional crypto is not needed
> here to achieve authentication because of IPSec.

Yes, you're right, this is crucial.

Fortunately GSS-API provides a mechanism for dealing with channel
bindings.  CCM has to ensure that GSS contexts established through it
are correctly bound to the underlying network layer security.  I think
it will; there's certainly nothing to impede it.

We[*]'ve had some conversations about this here at Connectathon '03 and
the upshot is that CCM has to have channel bindings binding CCM GSS
contexts to the underlying network security mechanisms.  IPsec, IKEv2,
SSHv2, etc... must each have a CCM channel binding type.  The channel
bindings in question will have to bind to cryptographically secure
channel identifiers.  GSS channel bindings can be optional, of course,
at the accpeptor's discretion.  In practice this means that the
initiator's tokens must provide for the optional inclusion of typed CCM
channel binding data and the acceptor's tokens must provide for the
optional inclusion of a MIC of the typed CCM channel binding data.

One very neat side effect of having CCM channel bindings for binding to
the underlying network is that you can have anonymous IPsec/whatever
connections and still use CCM - Secure NFS over anonymous IPsec if you
wish.

[*] Sam Hartman, Tom Yu, Mike Eisler, myself.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Eisler | 2 Mar 2003 08:07

Re: ACL in NFSv4 protocol

> From: "Sergey Klyushin" <sergey.klyushin <at> hummingbird.com>

> I. Synchronization of ACL and mode.

> ================ from protocol ====================================
> 5.11.6.  Mode and ACL Attribute

>    The server that supports both mode and ACL must take care to
>    synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the
>    ACEs which have respective who fields of "OWNER <at> ", "GROUP <at> ", and
>    "EVERYONE <at> " so that the client can see semantically equivalent access
>    permissions exist whether the client asks for owner, owner_group and
>    mode attributes, or for just the ACL.

>    Because the mode attribute includes bits (e.g. MODE4_SVTX) that have
>    nothing to do with ACL semantics, it is permitted for clients to
>    specify both the ACL attribute and mode in the same SETATTR
>    operation. However, because there is no prescribed order for
>    processing the attributes in a SETATTR, the client must ensure that
>    ACL attribute, if specified without mode, would produce the desired
>    mode bits, and conversely, the mode attribute if specified without
>    ACL, would produce the desired "OWNER <at> ", "GROUP <at> ", and "EVERYONE <at> "
>    ACEs.
> ====================== end ====================================

> Why mode MUST be synchronized with ACL? Does any OS do it? Windows does not.

Because we don't know what it means to have mode be in conflict
with the corresponding ACEs.
(Continue reading)

Permalink | Reply | 539 comments |
headers
wurzl, mario | 2 Mar 2003 18:17

RE: ACL in NFSv4 protocol


> -----Original Message-----
> From: Mike Eisler [mailto:mike <at> eisler.com]
> Sent: Sunday, March 02, 2003 2:08 AM
> To: nfsv4-wg <at> sunroof.eng.sun.com; sergey.klyushin <at> hummingbird.com
> Cc: Dave.Noveck <at> netapp.com; beame <at> bws.com; spencer.shepler <at> sun.com
> Subject: Re: ACL in NFSv4 protocol
> 
> 
> > From: "Sergey Klyushin" <sergey.klyushin <at> hummingbird.com>
> 
> > I. Synchronization of ACL and mode.
> 
> > ================ from protocol ====================================
> > 5.11.6.  Mode and ACL Attribute
> 
> >    The server that supports both mode and ACL must take care to
> >    synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH 
> bits with the
> >    ACEs which have respective who fields of "OWNER <at> ", "GROUP <at> ", and
> >    "EVERYONE <at> " so that the client can see semantically 
> equivalent access
> >    permissions exist whether the client asks for owner, 
> owner_group and
> >    mode attributes, or for just the ACL.
> 
> >    Because the mode attribute includes bits (e.g. 
> MODE4_SVTX) that have
> >    nothing to do with ACL semantics, it is permitted for clients to
> >    specify both the ACL attribute and mode in the same SETATTR
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Eisler | 3 Mar 2003 00:39

Re: NFSv4 Locking case study

> From: Stevan Steve Allen <scallen <at> us.ibm.com>
> Date: Thu, 27 Feb 2003 01:28:03 -0800

[...]
> Given applications which support byte range, or file share, semantics are
> considered well behaved Applications which do not support such semantics
> are considered rouge applications according to file access needs of various
> customer solutions and platforms.  Such rouge applications may need to be
> restricted from access.

I don't think there's anything you can do about applications
that refuse to honor the application specific handshake for
accessing the file.

> Need:

> To ensure proper semantics, range level sharing solutions for performance
> may require file share only or stateid of all zeros implementations to be

Note that all bits zeros stateids come from the client, not the application.

> restricted.  Clients should not interpret this error as re-tryable.  For
> reference, the NFSv4 draft mentions similar byte range semantic enforcement
> (chpt. 8. "for example, some UNIX-based servers").   We suspect a need for
> a specific error to represent this condition.   NFS4ERR_LOCKED is not
> appropriate as it signifies a re-tryable condition.  We are proposing an
> permanent error to be returned to the application layer.

What if the application then decides to retry? How has this
solved anything?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Carl Beame | 3 Mar 2003 10:48
Favicon

Re: ACL in NFSv4 protocol

Given the following what does "Synchronization" mean?

File: rwx------ (700) Owner Read/Write/Execute
on local system an ACL is added which contains one ACE:
	"FRED" - DENY WRITE

FRED is the owner of the file.

A local "ls" command will list the file as:
	rwx------

From an NFS connected machine, the mode will be?????

	r-x------ or rwx------ 

If Synchronized that I would assume you mean r-x------.

Now a CHOWN is done to CARL so what are the permissions on the file???

rwx------ with an ACE for FRED which denies him WRITE??

So the "Synchronized" ls changes the displayed mode to rwx------ from r-x------?

Is the above scenario different if the ACE is OWNER <at>  ???

-------------------------------------------------

I should note that my intention was the OWNER and GROUP were placeholders which
matched the current owner and current group, but were not "storable" values. The
real current owner and group would be inserted in the ACE before it went to
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gordon Waidhofer | 3 Mar 2003 11:28

RE: ACL in NFSv4 protocol

I believe for a POSIX ACL, the example would be:

	owner=fred					fred <at> foo
	ACL_USER_OBJ			rwx	OWNER <at> 
	ACL_USER		fred		r-x	fred <at> foo

A chown would not affect the ACL.

A strict interpretation of POSIX ACL rules is that
because fred matches ACL_USER_OBJ, no ACL_USER for
fred would be relavent. The odd part is that this is true
even if the ACL_USER for fred grants more rights
than ACL_USER_OBJ. The later prevails with its
narrower rights.

Now, of course, the tricky question is what are the
semantics of NFSv4 ACLs?

	-gww

> -----Original Message-----
> From: owner-nfsv4-wg <at> sunroof.eng.sun.com
> [mailto:owner-nfsv4-wg <at> sunroof.eng.sun.com]On Behalf Of Carl Beame
> Sent: Monday, March 03, 2003 1:49 AM
> To: nfsv4-wg <at> sunroof.eng.sun.com
> Subject: Re: ACL in NFSv4 protocol
> 
> 
> Given the following what does "Synchronization" mean?
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Carl Beame | 3 Mar 2003 14:21
Favicon

RE: ACL in NFSv4 protocol

On Mon Mar 03 10:28:11 2003, Gordon Waidhofer wrote:
> 
> I believe for a POSIX ACL, the example would be:
> 
> 	owner=fred					fred <at> foo
> 	ACL_USER_OBJ			rwx	OWNER <at> 
> 	ACL_USER		fred		r-x	fred <at> foo
> 
> A chown would not affect the ACL.
> 

I don't understand POSIX ACLs, but I didn't say there was an ACL for FRED <at> FOO, I
just said there was a mode (700). Does this mean on POSIX that it automatically
creates an ACL for user FRED???? On non-POSIX systems, were ACLs not separate
entities and doing a "CHMOD 700 l.l" just set the mode in the inode and did
nothing to the ACLs. Adding an ACL for a specific user, did it also create ACEs
for the "OWNER", "GROUP", "OTHER"???

> 
> Now, of course, the tricky question is what are the
> semantics of NFSv4 ACLs?
> 

Good question.

- Carl
Permalink | Reply | 1 comment |
headers
Mike Eisler | 3 Mar 2003 18:51

Re: ACL in NFSv4 protocol

> From owner-nfsv4-wg <at> sunroof.eng.sun.com  Mon Mar  3 02:15:16 2003
> Given the following what does "Synchronization" mean?

> File: rwx------ (700) Owner Read/Write/Execute
> on local system an ACL is added which contains one ACE:
> 	"FRED" - DENY WRITE

> FRED is the owner of the file.

> A local "ls" command will list the file as:
> 	rwx------

I hope not.

> >From an NFS connected machine, the mode will be?????

> 	r-x------ or rwx------ 

> If Synchronized that I would assume you mean r-x------.

If the implementation automatically reflects FRED's DENY WRITE into the
OWNER <at>  DENY, then the former (r-x ...).

> Now a CHOWN is done to CARL so what are the permissions on the file???

> rwx------ with an ACE for FRED which denies him WRITE??

That's my understanding.

> So the "Synchronized" ls changes the displayed mode to rwx------ from r-x------?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sergey Klyushin | 3 Mar 2003 19:16
Favicon

RE: ACL in NFSv4 protocol


> -----Original Message-----
> From: Mike Eisler [mailto:mike <at> eisler.com]
> Sent: Saturday, March 01, 2003 11:08 PM
> To: nfsv4-wg <at> sunroof.eng.sun.com; sergey.klyushin <at> hummingbird.com
> Cc: Dave.Noveck <at> netapp.com; beame <at> bws.com; spencer.shepler <at> sun.com
> Subject: Re: ACL in NFSv4 protocol
> 
> > From: "Sergey Klyushin" <sergey.klyushin <at> hummingbird.com>
> 
> > I. Synchronization of ACL and mode.
> 
....... (removed)
> 
> > Why mode MUST be synchronized with ACL? Does any OS do it? Windows does
> not.
> 
> Because we don't know what it means to have mode be in conflict
> with the corresponding ACEs.
> 

Actually synchronization (if needed) should be done not with "OWNER <at> ", 
"GROUP <at> ", and "EVERYONE <at> " ACEs, but with access rights that user may
approximate from mode and from ACL. In this case OWNER <at> /GROUP <at>  (as POSIX 
ACL_USER_OBJ/ ACL_GROUP_OBJ) are not necessary.

> Since mode is a UNIX thing, I don't see how you can say Windows
> does not. A Windows NFSv4 server should be able to derive mode from the
> corresponding ACEs.
(Continue reading)

Permalink | Reply | 538 comments |
headers
Sergey Klyushin | 3 Mar 2003 19:53
Favicon

RE: ACL in NFSv4 protocol


> -----Original Message-----
> From: Mike Eisler [mailto:mike <at> eisler.com]
> Sent: Saturday, March 01, 2003 11:08 PM
> To: nfsv4-wg <at> sunroof.eng.sun.com; sergey.klyushin <at> hummingbird.com
> Cc: Dave.Noveck <at> netapp.com; beame <at> bws.com; spencer.shepler <at> sun.com
> Subject: Re: ACL in NFSv4 protocol
> 
> > From: "Sergey Klyushin" <sergey.klyushin <at> hummingbird.com>
> 
> > Protocol says
> > ======================================
> >    ACE4_NO_PROPAGATE_INHERIT_ACE
> 
> >    Can be placed on a directory. Normally when a new directory is
> >    created and an ACE exists on the parent directory which is marked
> >    ACL4_DIRECTORY_INHERIT_ACE, two ACEs are placed on the new directory.
> >    One for the directory itself and one which is an inheritable ACE for
> >    newly created directories.  This flag tells the server to not place
> >    an ACE on the newly created directory which is inheritable by
> >    subdirectories of the created directory.
> > ======================================
> > "Normally" creating two ACEs is implementation depended.
> 
> I don't think so. The text is just saying what happens
> when _NO_PROPOGATE_ is set.
> 

No, the text says about "Normally" setting two ACEs on a newly created 
directory if parent directory has ACE with INHERIT flag, and setting
(Continue reading)

Permalink | Reply | 0 comments |

Gmane