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

From: Lisa Week <[email-masked]>
Date: Tue, 08 Aug 2006 22:41:46 -0600

Hi all,

Here are the raw notes taken from today's ACL design team meeting.

We will do a summary of the conclusions drawn from the meetings after  
Thursday's meeting (which is the last day).

I will be sending out another email shortly with the proposed agenda  
for tomorrow.

Thanks,
Lisa

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

---

From: [email-masked]
Date: Wed, 9 Aug 2006 11:07:00 -0400

I added some comments to the notes

Mario

-----Original Message-----
From: Lisa Week [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 00:42
To: [email-masked]
Subject: [nfsv4] Raw notes from today's ACL meeting

Hi all,

Thanks,
Lisa

---

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

Everhart, Craig wrote:
>> From: Peter Staubach [mailto:[email-masked]] 
>> Yoder, Alan wrote:
>>     
>>> 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.
>>>       
>> 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.
>>     
>
> Why doesn't your client use the ACCESS op to see if some new user should
> have access to the cached data?  As one might say, not doing this opens
> a security hole.
>   

Because the NFSv2 protocol does not contain the ACCESS protocol operation...

This is one of the reasons why the ACCESS operation was added to the NFSv3
protocol.

It is also the reason that I added ACCESS and GETATTR operations to the
NFS_ACL version 2 protocol.

    Thanx...

       ps

---

From: [email-masked]
Date: Thu, 10 Aug 2006 11:21:38 -0400 (EDT)

> Stupid question of the thread:  How many people still use NFS V2?
> And are they all Cobol programmers?  And please don't forget the Cobol
> program that actually used "Unix file record locking" to lock offset
> 5-6 to refer to bytes 400-560.  (80 column fixed length records and all
> that - as Ric types into his 80 column emacs window.)

I've thought the same thing, and I'm the guy who still uses "ed" as my
text editor:-). On a slightly more serious note, I asked this on some
mailing lists recently and, at least in bsd world, the only interest in
nfsv2 clients was for bootstrapping weird diskless devices. (I don't think
how the mode bits look is going to matter much for that.)

rick
ps: Who is typing this into "ed" on an 80x24 text screen...

---

From: "Yoder, Alan" <[email-masked]>
Date: Mon, 14 Aug 2006 14:14:37 -0700

> 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.

   I originally brought this up because Netapp has had
enough complaints to motivate us to change the behavior
of our server.  However, since the consensus seems
to be that we are not going to force v4-compliant servers 
to worry about v2 clients, I suggest we move on.  

   This means individual vendors can just keep doing 
whatever they were already doing.  A nice outcome.  ;)

Alan

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