From: Gordon Waidhofer (gww@traakan.com)
Date: 12/16/04-08:11:26 PM Z
From: "Gordon Waidhofer" <gww@traakan.com>
Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Date: Thu, 16 Dec 2004 18:11:26 -0800
Message-ID: <HIEGIBOPEMBFAKKGEELDEELAJAAA.gww@traakan.com>
> Take 3 hypothetical servers, A, B, and C:
>
> Server A decides that it's going to determine permissions to read/write
> its named attributes by looking at read/write bits on the file.
>
> server B decides it's going to determine permissions to read/write
> extended attributes in the way others on the list have suggested--write
> to owner only, read to everyone.
>
> Server C has full NFSv4 acl support, and allows the *_NAMED_ATTRIBUTE
> bits to be set independently of the other bits.
All three of these examples assume that one set of permission bits
apply to all subfiles (named attributes). Probably the case
for present day NTFS, though there is some indication NTFS will
have to address security holes raised by streams (subfiles).
Solaris subfiles (extended attributes), on the other hand, are
much more fine grained. Each subfile has its own set of permissions.
Indeed, each subfile could have its own ACL, owner, mtime, ctime,
etc, etc.
The difference is no small point.
As much as I like the Solaris approach (quite aesthetic, though
misnamed), I have to worry about its influence on NFSv4 semantics.
The file model could easily become something NTFS can't or won't do.
I've no answers at this time. It would be nice if we knew more
about what NTFS is going to do about its subfile security holes.
So, restraint on anything and everything related to NFSv4 Named
Attributes (subfiles, that should be renamed too) is advisable.
Regards,
-gww
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
This archive was generated by hypermail 2.1.2 : 03/04/05-02:13:49 AM Z CST