Subject: RE: [nfsv4] Raw notes from today's ACL meeting

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 9 Aug 2006 12:16:18 -0700

> >> - Bruce said to add: "Don't allow the the permissions to be more
> >>     
> > permissive than what would be given when setting the mode." 
>  This was
> > agreed to be a good thing. 
> >
> > Caveat: as I said before, this can cause v2 clients to mistakenly
> > assume they can't access a file in some cases, when they 
> actually could.
> > That's because you end up using a mode less permissive than the ACL,
> > if you've been told not to use one that's more permissive.
> > I'd like to see the standard allow more permissive modes in v2 stat
> > calls to work around this issue.
> 
> Will this not allow some clients to incorrectly decide that access
> should be permitted, this introducing a security issue?
> 
> It seems to me that denying access to a file is better than allowing
> access incorrectly, unless the environment is known in advance.

No, the server should always use the ACL to decide whether
to grant access or not.  This is the confusing part--these
display/stat-only modes don't actually determine access, they
are informational only.

The v2 scenario is that the client checks the mode to see 
whether access will be granted before actually attempting 
the access.  If the server is ginning up a more restrictive 
mode to represent the ACL, the client gives up in some edge 
cases when it shouldn't.  

This made our phone ring often enough that we changed the
behavior of our server (under an option I believe) to be
more-permissive for v2 clients. 

Useful definitions: more-permissive --  the mode allows everything
						    that the ACL allows
			  more-restrictive -- the mode denies everything
						    that the ACL denies

It turns out that for synthesized modes, more-permissive
works best for v2 clients, and less-restrictive works well
for v3 (and POSIX ?) clients.

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
===============================================================

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Peter Staubach <[email-masked]>
Date: Wed, 09 Aug 2006 15:27:15 -0400

> display/stat-only modes don't actually determine access, they

Actually, this is correct, but only from a server viewpoint.  The client
uses the mode to determine whether to allow a user access to cached data
and if that mode allows the user to have more permissions than that user
should otherwise, then a security hole has been opened.

> mode to represent the ACL, the client gives up in some edge 

Right.  But the opposite also can allow access to data that that
user should not have had access to.

> for v3 (and POSIX ?) clients.

The default for Solaris is exactly the opposite.  By default, the Solaris
NFSv2 server computes the most restrictive set of permissions to express
in the mode.  There is an export option to compute the least restrictive
set of permissions for the mode, but it is not the default.

I wonder if those customers, who complained about the situation, knew
exactly what they were opening themselves up for...

       ps

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 9 Aug 2006 17:58:58 -0400

> should otherwise, then a security hole has been opened.

This is an unsolveable problem.  So we're not going to try to solve it.

We obviously cannot require that the mode correctly represent the ACL.
However, it would be helpful for the server to have *some* clear
relationship to the ACL, so that it's possible to form at least some
inferences about the ACL with knowledge only of the mode.  Two obvious
relationships the mode could have to the ACL are:

	1) The mode is an "upper bound" on the ACL.  So any access that
	would be permitted by the ACL would also be permitted by the
	mode.
	2) The mode is a "lower bound" on the ACL.  So any acceess that
	would be permitted by the mode would also be permitted by the
	ACL.

Either option breaks something.  Option 1 seems the least bad option for
a variety of reasons, including that a user looking only at the mode
will not assume that the permissions are stricter than they really are,
as rfc3530 already points out.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 9 Aug 2006 18:03:18 -0400

> However, it would be helpful for the server to have *some* clear
				       ^^^^^^

Err, the word "server" should have been "mode" there.

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 09 Aug 2006 18:29:33 -0400

> > as rfc3530 already points out.

I disagree. Option 1 will cause by far the worst breakages: An NFSv2
client will readily allow access to cached data to applications that
don't have the necessary privileges, but then said applications will get
an unexpected EACCESS on the first actual request to go on the wire.

Cheers,
  Trond

---

From: Peter Staubach <[email-masked]>
Date: Thu, 10 Aug 2006 08:45:02 -0400

> an unexpected EACCESS on the first actual request to go on the wire.

I would agree with this.  Option #2 has been the Solaris NFS server policy
since 1995, with a minimal number of complaints.  Off hand, I can't actually
remember any, but I am sure that there must have been someone, someplace,
who was surprised and had to have the situation explained to them.  In any
case, there were no fixes made to the code or to the defaults.

    Thanx...

       ps

---

From: "J. Bruce Fields" <[email-masked]>
Date: Sun, 13 Aug 2006 15:26:24 -0400

On Thu, Aug 10, 2006 at 08:45:02AM -0400, Peter Staubach wrote:
> since 1995, with a minimal number of complaints.

I'm not sure what you mean by that.  It looks quite possible for Solaris
to return mode bits that may appear to permit access that's actually
forbidden; e.g. this denies andros read even if andros is a member of
"other":

# ls -l foo
-rw-rw-r--+  1 bfields     other           0 Aug 13 15:20 foo
# getfacl foo
# file: foo
# owner: bfields
# group: other
user::rw-
user:andros:r--         #effective:r--
group::rw-              #effective:rw-
mask:rw-
other:r--

I haven't tried to fetch that mode bit over NFSv2, but I assume it's not
returning different mode bits over v2?

--b.

---

From: Peter Staubach <[email-masked]>
Date: Mon, 14 Aug 2006 11:07:45 -0400

> returning different mode bits over v2?

That's exactly what I've been trying to tell you.  We are talking about
NFSv2 _only_ here.  The mode is not really used in either NFSv3 or NFSv4
when attempting to determine access; the ACCESS operation is used instead.

The Solaris NFSv2 server maps the returned mode based on any ACLs which
might be present on the file.  The default is to minimize the mode to
the minimum allowed set of bits.  This done to prevent clients from
incorrectly allowing access to data which should not have been permitted.
The downside is that clients may incorrectly deny access which should
have been allowed.

This was all implemented in 1995 and there have been few, if any, complaints
since.

       ps

---

From: Peter Staubach <[email-masked]>
Date: Mon, 14 Aug 2006 11:31:18 -0400

J. Bruce Fields wrote:
> On Mon, Aug 14, 2006 at 11:07:45AM -0400, Peter Staubach wrote:
>   
> OK, got it.
> So allowing NFSv2 to return different mode bits from what would be
> returned to v3, v4, or local users, never causes problems?  I guess I
> don't see any reason why it should; it just seems strange.  Does
> mode-setting also behave differently under v2?  (And, if not, do people
> complain when the mode set isn't the mode returned by a subsequent
> stat()?)
>   

I don't believe that mode setting was modified.  The mode is the mode, 
as Sam
and Lisa tried to describe.

It has been a while, but I don't recall there being a large number of
complaints.  Part of this might have been that NFSv3 was introduced at
the same time, so people switched to it and it did not have this particular
"feature".  Also, Solaris to Solaris systems, 2.6 and newer, were not 
subject
to this issue because they used the GETATTR operation from the NFS_ACL
protocol which specifically does not map the mode in the returned 
attributes.
(That's why it was introduced...)

    Thanx...

       ps

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 14 Aug 2006 11:22:03 -0400

OK, got it.

--b.