NFSv4 ACL and POSIX interaction / mask

NFSv4 ACL and POSIX interaction / mask

[Andreas Gruenbacher]

Hello,

I have been thinking about the problems of interaction between NFSv4 ACLs and 
POSIX, and particularly about the issue of masking permissions through chmod 
and after creating files or directories.

On a UNIX system that supports NFSv4 ACLs natively, I think we should try to 
accept as wide a range of NFSv4 ACLs as possible, but we must make sure that 
we can preserve POSIX semantics. In particular, this means that ACLs may 
contain ACEs for users other than OWNER@, GROUP@, and EVERYONE@, and that 
chmod(2) must continue to provide the same kinds of guarantees as without 
NFSv4 ACLs.

I am assuming here that NFSv4 ACLs shall be an additional rather than an 
alternate file access control mechanism in the POSIX sense: Alternate file 
access control mechanisms must ``be enabled only by explicit user action, on 
a per-file basis by the file owner or a user with the appropriate 
privilege'', and must ``be disabled for a file after the file permission bits 
are changed for that file with chmod( )'' according to POSIX. In other words, 
newly created files or directories would have alternate file access control 
mechanisms disabled. This would render NFSv4 ACLs essentially useless for 
UNIX processes, because they would almost always be disabled, and would only 
work for remote processes until a POSIX process chmods a file or creates a 
directory, which wouldn't get us very far.

Let's look at chmod(2): the mode specified in chmod(2) defines the permissions 
of three classes of users: owner, group, and other. Each class is assigned a 
set of the READ, WRITE, and EXECUTE permissions. This defines the maximum set 
of permissions that this class has at any moment.

In an NFSv4 ACL, each entry must be in exactly one of the three classes of 
users: OWNER@ is in the owner class, GROUP@ and additional users and groups 
listed in the ACL are in the group class, and EVERYONE@ is in the other 
class.

No ACL entry shall granted permissions that exceed the permissions of its 
class. (Additional permissions in a class could be enabled explicitly, which 
would amount to an alternate file access mechanism, though.)

Note that we must not allow an ACE to be in no class, either: if we did, a 
chmod call with mode 0 would not disable all access, which would conflict 
with POSIX.

Note that this definition is in line with POSIX 1003.1e draft 17 [2], while it 
conflicts with the IETF NFS Version 4 ACLs draft [1], which associates only 
GROUP@ entries with the group file mode permission bits in section 5.1. The 
relevant text of IETF NFS Version 4 ACLs draft [1] is also found in NFSv4 
Minor Version 1 [4].

We want chmod(2) to be non-destructive, so that a chmod to a more restrictive 
mode and back to the original mode will leave the file with the same 
permissions as before the changes.

According to NFS Version 4 ACLs [1], it has been tried to replace the entire 
ACL with an ACL that only grants the permissions specified by the new mode. 
This approach has two drawbacks: first, it is destructive, and additional 
permissions granted are lost in the first chmod. Second, additional 
restrictions (DENY entries) may be lost as well. This is not acceptable, and 
unsurprisingly, users did not favor this approach.

POSIX ACLs have solved the non-destructiveness problem by introducing a mask 
ACL entry: the mask entry applies to all group class entries, and defines an 
upper bound to the permissions those entries may grant. POSIX ACLs only have 
ACL entries that allow permissions, and only specify READ, WRITE, and EXECUTE 
permissions. Therefore, the owner class and other class permissions are the 
permissions granted to the owner and to others, respectively. (Note the 
difference between these others and NFSv4's EVERYONE@ special identifier).

The mask concept is not part of NFSv4 ACLs. Marius A. Eriksen and others have 
proposed to emulate the POSIX ACL mask entry by prepending (with exception of 
OWNER@ and EVERYONE@ ACEs) each ALLOW ACE with a DENY ACE for the same user, 
group, or special identifier as in the ALLOW ACE. The permissions in the DENY 
ACE are set so that the entry denies the permissions not granted by the mask.

Unless we accept a very specific form of NFSv4 ACLs only (which would 
contradict the goal stated at the top of this message, and which would mean 
that interoperability with anything but POSIX ACLs would become difficult), 
there is no easy way to tell DENY entries introduced to emulate the mask from 
DENY entries added by hand. This has two potential consequences:

 - First, if we fail to identify such a mask-emulation DENY entry, we may end 
up inserting another such entry. We might end up doing so repeatedly.

 - Second, we may take a user-provided DENY entry for a mask-emulation DENY 
entry, and clear mask bits from that entry. This would contradict the user's 
intention. So the approach of inserting mask-emulation DENY entries is not 
good enough in general. (Mapping between NFSv4 and POSIX ACLs does not have 
this problem, because POSIX ACLs don't have DENY ACEs.)

In my opinion, there are two possible solutions for this problem: we can (1) 
devise a special kind of NFSv4 ACL entry that we will recognize as mask 
entry, or (2) give the owner/group/other class permission bits higher 
priority than the ACL entries, and only allow permissions that are allowed by 
both the ACEs and their associated classes.

In case (1), we could either keep prepending (almost) each ALLOW entry with an 
associated DENY entry and set a special flag in the DENY entry, or we could 
introduce something like a MASK@ special identifier, add MASK@ entries to the 
ACL in the appropriate places, and add the mask logic to the permission check 
algorithm.

We would need at most three MASK@ entries per ACL, one for each class of 
users: it should be obvious that we need a mask for the group class, which 
contains the GROUP@ entries and all entries for explicitly named users and 
groups. We want to avoid destroying permissions set explicitly for USER@ and 
EVERYONE@ entries after a chmod as well though. We could then use the mask 
mechanism to selectively turn on additional permissions not covered by READ, 
WRITE, and EXECUTE, as a kind of alternate file access control mechanism.

We could keep such extensions local to the server and not expose them over the 
protocol, with the obvious interoperability problems when copying files 
around, or we could make whichever extensions we need part of the NFSv4 
protocol.

Case (2) would be pretty simple to implement, but all permissions that are not 
covered by READ, WRITE, EXECUTE would always be masked (for correctness, even 
for remote clients), and there would be no controlled way to un-mask them.

Thoughts anyone?

Thanks,
Andreas

REFERENCES

[1] Sam Falkner et al.: NFS Version 4 ACLs, draft-ietf-nfsv4-acls-00.txt

[2] POSIX 1003.1e/2c draft 17 (withdrawn), 
http://wt.xpilot.org/publications/posix.1e

[3] Marius Aamodt Eriksen et al.: Mapping Between NFSv4 and Posix Draft ACLs, 
draft-ietf-nfsv4-acl-mapping-04.txt

[4] Spencer Shepler (editor): NFSv4 Minor Version 1, 
draft-ietf-nfsv4-minorversion1-03.txt

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

On Monday, 3. July 2006 23:10, Andreas Gruenbacher wrote:
> Hello,
>
> I have been thinking about the problems of interaction between NFSv4 ACLs
> and POSIX, and particularly about the issue of masking permissions through
> chmod and after creating files or directories.

Here is a follow-up after some personal feedback from Sam. I believe that 
draft-ietf-nfsv4-acls-00 is not ready to become part of the NFSv4 Minor 
Version 1 RFC: some assumptions are not correct from a POSIX point of view, 
and the way how chmod and file create modes are applied to NFSv4 ACLs is weak
and not guaranteed to be correct.

I will first try to clarify some of the points I tried to make in the previous 
posting and point out deficiencies in draft-ietf-nfsv4-acls-00. Then I will 
propose an alternative design which is more correct than introducing DENY 
entries to mask permissions. (As a bonus, it is easier to implement. too.)

> On a UNIX system that supports NFSv4 ACLs natively, I think we should try
> to accept as wide a range of NFSv4 ACLs as possible, but we must make sure
> that we can preserve POSIX semantics. In particular, this means that ACLs
> may contain ACEs for users other than OWNER@, GROUP@, and EVERYONE@, and
> that chmod(2) must continue to provide the same kinds of guarantees as
> without NFSv4 ACLs.
>
> I am assuming here that NFSv4 ACLs shall be an additional rather than an
> alternate file access control mechanism in the POSIX sense: Alternate file
> access control mechanisms must ``be enabled only by explicit user action,
> on a per-file basis by the file owner or a user with the appropriate
> privilege'', and must ``be disabled for a file after the file permission
> bits are changed for that file with chmod( )'' according to POSIX. In other
> words, newly created files or directories would have alternate file access
> control mechanisms disabled. This would render NFSv4 ACLs essentially
> useless for UNIX processes, because they would almost always be disabled,
> and would only work for remote processes until a POSIX process chmods a
> file or creates a directory, which wouldn't get us very far.

As Sam pointed out, a subset of NFSv4 ACLs maps to an additional file access 
control mechanism, while the rest goes beyond that, and therefore is an 
alternate file access control mechanism.

It is important to understand how POSIX defines additional file access control 
mechanisms:

[] 3.4 Additional File Access Control Mechanism
[] An implementation-defined mechanism that is layered upon the access control
[]  mechanisms defined here, but which do not grant permissions beyond those
[]  defined herein, although they may further restrict them.

In other words, when a file has just been created and after chmod, the file 
mode permission bits define an upper bound to the permissions granted to 
anyone on the system, and nobody has additional permissions. Additional 
permissions (as an alternate file access control mechanism) may be 
enabled explicitly, but the next chmod must disable them again.

We can classify the permissions that NFSv4 ACLs grant into additional and 
alternate mechanisms as follows: everything covered by the POSIX 
read/write/execute permissions (such as ACE4_READ_DATA, but also 
ACE4_APPEND_DATA) is additional, while everything beyond that (such as 
ACE4_WRITE_OWNER) is alternate. Under this definition, all NFSv4 ACLs that 
grant no more than ACE4_READ_DATA, ACE4_LIST_DIRECTORY, ACE4_WRITE_DATA, 
ACE4_ADD_FILE, ACE4_APPEND_DATA, ACE4_ADD_SUBDIRECTORY, 
ACE4_READ_NAMED_ATTRS, ACE4_WRITE_NAMED_ATTRS, ACE4_EXECUTE, 
ACE4_READ_ATTRIBUTES, ACE4_WRITE_ATTRIBUTES, ACE4_READ_ACL, and 
ACE4_SYNCHRONIZE would count as additional access control mechanisms. All 
others with ACE4_WRITE_ACL, ACE4_WRITE_OWNER, ACE4_DELETE_CHILD, and 
ACE4_DELETE are alternate.

As said already, the POSIX file mode permission bits define the permissions of 
three classes: owner, group, and other. An additional file access control 
mechanism may only further restrict the permissions granted to those classes.

To map NFSv4 ACLs to an additional file access control mechanism,

 - we must map each NFSv4 ACL entry to exactly one of the three classes.

 - we must ensure that the ACL does not grant any permissions that go beyond
   the class permissions after a chmod or create.

 - in particular, we must ensure that the ACL grants no "alternate"
   permissions after a chmod or create.

We are free to provide mechanisms by which more permissions may be enabled by 
explicit user action, on a per-file basis by the file owner or a user with 
the appropriate privilege, according to POSIX.

The POSIX definitions of the three file permission classes are:

[] 3.173 File Owner Class
[] The property of a file indicating access permissions for a process related
[] to the user identification of a process. A process is in the file owner
[] class of a file if the effective user ID of the process matches the user ID
[] of the file.

[] 3.166 File Group Class
[] The property of a file indicating access permissions for a process
[] related to the group identification of a process. A process is in
[] the file group class of a file if the process is not in the file owner
[] class and if the effective group ID or one of the supplementary group
[] IDs of the process matches the group ID associated with the file. Other
[] members of the class may be implementation-defined.

[] 3.172 File Other Class
[] The property of a file indicating access permissions for a process related
[] to the user and group identification of a process. A process is in the file
[] other class of a file if the process is not in the file owner class or file
[] group class.

The key fact in these definitions is that an implementation may define 
additional members of the File Group Class, while the other classes are not 
extensible.

Under this definition, we end up with the following mapping:

 - OWNER@ entries are in the File Owner Class,
 - EVERYONE@ entries are in the File Other Class,
 - every other entry is in the File Group Class(*).

 (*) User entries for the user who is the current file owner are a special
     case: due to how the NFSv4 ACL permission check algorithm is specified,
     I believe that they should be put in the OWNER@ class.

> Note that this definition is in line with POSIX 1003.1e draft 17 [2], while
> it conflicts with the IETF NFS Version 4 ACLs draft [1], which associates
> only GROUP@ entries with the group file mode permission bits in section
> 5.1. The relevant text of IETF NFS Version 4 ACLs draft [1] is also found
> in NFSv4 Minor Version 1 [4].

Section 5.1 of [1] needs to be fixed: we must set the permission bits so that 
they are a superset of the permissions of all the entries in the respective 
class. (We cannot represent permissions that are not supersets of 
POSIX read, write, execute in the class, but that is not a problem, as we will 
see later.)

Non-monotonic permissions
=========================

Note that with arbitrary NFSV4 ACLs, the permissions granted to a process from 
multiple ACL entries will accumulate. This means that permissions across 
multiple classes may accumulate as well. This can be prevented with DENY 
entries in the ACL, e.g.,

	OWNER@:mask1::ALLOW
	OWNER@:^mask1::DENY
	user@domain:mask2::ALLOW
	group@domain:mask3:ACE4_IDENTIFIER_GROUP:ALLOW
	user@domain:^mask2::DENY
	group@domain:^mask3:ACE4_IDENTIFIER_GROUP:DENY
	EVERYONE:mask4::ALLOW

This means that we will not have to deal with this special case when computing 
the file mode permission bits, and we can achieve consistency by forcing ACLs 
to be "well structured".

We could also leave this as an implementation consideration: ACLs which are 
not "well structured" in the above sense will grant permissions that go 
beyond what an additional access control mechanism may grant *only* for 
non-monotonic file mode permission bits. With non-monotonic I mean file mode 
permission bits which grant more permissions to the group class than to the 
owner class, or more permissions to the other class than to the group class. 

> We want chmod(2) to be non-destructive, so that a chmod to a more
> restrictive mode and back to the original mode will leave the file with the
> same permissions as before the changes.
>
>[...]
>
> POSIX ACLs have solved the non-destructiveness problem by introducing a
> mask ACL entry: the mask entry applies to all group class entries, and
> defines an upper bound to the permissions those entries may grant. POSIX
> ACLs only have ACL entries that allow permissions, and only specify READ,
> WRITE, and EXECUTE permissions. Therefore, the owner class and other class
> permissions are the permissions granted to the owner and to others,
> respectively. (Note the difference between these others and NFSv4's
> EVERYONE@ special identifier).
>
> The mask concept is not part of NFSv4 ACLs. Marius A. Eriksen and others
> have proposed to emulate the POSIX ACL mask entry by prepending (with
> exception of OWNER@ and EVERYONE@ ACEs) each ALLOW ACE with a DENY ACE for
> the same user, group, or special identifier as in the ALLOW ACE. The
> permissions in the DENY ACE are set so that the entry denies the
> permissions not granted by the mask.

Internet draft-ietf-nfsv4-acls-00.txt [1] uses the same mechanism to implement 
masking.

> Unless we accept a very specific form of NFSv4 ACLs only (which would
> contradict the goal stated at the top of this message, and which would mean
> that interoperability with anything but POSIX ACLs would become difficult),
> there is no easy way to tell DENY entries introduced to emulate the mask
> from DENY entries added by hand. This has two potential consequences:
>
>  - First, if we fail to identify such a mask-emulation DENY entry, we may
> end up inserting another such entry. We might end up doing so repeatedly.
>
>  - Second, we may take a user-provided DENY entry for a mask-emulation DENY
> entry, and clear mask bits from that entry. This would contradict the
> user's intention. So the approach of inserting mask-emulation DENY entries
> is not good enough in general. (Mapping between NFSv4 and POSIX ACLs does
> not have this problem, because POSIX ACLs don't have DENY ACEs.)

Therefore, the mechanism described in section 5.3 is not suitable for our 
purposes, and we need to replace it with something better.

> In my opinion, there are two possible solutions for this problem: we can
> (1) devise a special kind of NFSv4 ACL entry that we will recognize as mask
> entry, or (2) give the owner/group/other class permission bits higher
> priority than the ACL entries, and only allow permissions that are allowed
> by both the ACEs and their associated classes.

A third option exists as well which fits in very well with POSIX and can be 
implemented in NFSv4 in a backward compatible way.

Alternative Proposal
====================

Instead of adding DENY entries to the ACL for the purpose of masking, attach 
three optional attributes to each file: owner_class_mask, group_class_mask, 
and other_class_mask. When those attributes are present, they define which 
permissions in an ACE are effective.

Each ACE is is restricted by one of these mask attributes in each access 
check:

 - OWNER@ entries and entries for the user@domain that currently owns the file
   are restricted by owner_class_mask.

 - EVERYONE@ entries are restricted by other_class_mask.

 - All other entries are restricted by group_class_mask.

The effective permissions are computed as the bitwise and (&) of the ACE mask 
and the associated class_mask attribute.

When doing a chmod(2) or when applying a create mask, the owner_class_mask, 
group_class_mask, and other_class_mask attributes are modified according to 
the owner class, group class, and other class permissions of the mode 
parameter as follows:

 - The POSIX read permission implies the ACE4_READ_DATA, ACE4_READ_ATTRIBUTES, 
ACE4_READ_ACL, and ACE4_SYNCHRONIZE bitmask flags.

 - The POSIX write permission implies the ACE4_WRITE_DATA, ACE4_APPEND_DATA, 
ACE4_WRITE_ATTRIBUTES, ACE4_DELETE_CHILD, and ACE4_SYNCHRONIZE bitmask flags.

 - The POSIX execute permission implies the ACE4_EXECUTE mask.

This saves us from bloating ACLs with DENY entries, is more efficient when 
doing a chmod, and also saves us from destroying permissions in user provided 
DENY entries.

When an ACL is set, then set all mask attributes to the values provided in the 
same SETATTR operation, and set the remaining mask attributes to the union of 
all ALLOW ACL entries in the ACL that the class applies to.

Without any further changes, NFSv4 clients not aware of the three optional 
attributes would not be aware of the restrictions imposed by those masks when 
querying for the ACL. This would create an interoperability problem, and 
possible security holes. To solve this problem, we can extend the GETATTR 
operation as follows:

When a client requests the ACL attribute, check if it also requests one or 
more of the three optional owner_class_mask, group_class_mask, or 
other_class_mask attributes. If it does, then send the requested attributes 
as they are. If the client requests only the ACL without any of the masks, 
return an ACL with only effective mask flags set, and with all other flags 
removed.

Alternate permissions in the ACL can be enabled by either setting an ACL 
without providing full mask entries, or by setting the appropriate bit(s) in 
the corresponding mask entry or entries.

When comparing POSIX ACLs and the NFSv4 ACL + mask attributes as proposed 
here, one obvious difference is that POSIX ACLs have only one mask entry, 
while I propose three mask entries here. The reason for this is that POSIX 
ACLs can at most grant read, write, and execute permissions, and so with 
POSIX ACLs, the File Owner Class permissions are always identical to the 
permissions granted to the owner, and the File Other Class permissions are 
always identical to the permissions granted to others. With NFSv4 ACLs, 
OWNER@ and EVERYONE@ entries may grant additional permissions that go beyond 
what POSIX read, write, and execute can grant, and we need a mechanism so 
that those alternate permissions can be turned off by chmod and during file 
create without destroying the permissions.



I would appreciate if you could take this alternative proposal into 
consideration when deciding how to proceed with NFSv4 Minor 
Version 1 at next week's IETF 66 meeting.


Thanks and best regards,
Andreas

> REFERENCES
>
> [1] Sam Falkner et al.: NFS Version 4 ACLs, draft-ietf-nfsv4-acls-00.txt
>
> [2] POSIX 1003.1e/2c draft 17 (withdrawn),
> http://wt.xpilot.org/publications/posix.1e
>
> [3] Marius Aamodt Eriksen et al.: Mapping Between NFSv4 and Posix Draft
> ACLs, draft-ietf-nfsv4-acl-mapping-04.txt
>
> [4] Spencer Shepler (editor): NFSv4 Minor Version 1,
> draft-ietf-nfsv4-minorversion1-03.txt

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Sam Falkner]

On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:

> On Monday, 3. July 2006 23:10, Andreas Gruenbacher wrote:
>> Hello,
>>
>> I have been thinking about the problems of interaction between  
>> NFSv4 ACLs
>> and POSIX, and particularly about the issue of masking permissions  
>> through
>> chmod and after creating files or directories.
>
> Here is a follow-up after some personal feedback from Sam. I  
> believe that
> draft-ietf-nfsv4-acls-00 is not ready to become part of the NFSv4  
> Minor
> Version 1 RFC: some assumptions are not correct from a POSIX point  
> of view,
> and the way how chmod and file create modes are applied to NFSv4  
> ACLs is weak
> and not guaranteed to be correct.

I disagree -- see below.

> I will first try to clarify some of the points I tried to make in  
> the previous
> posting and point out deficiencies in draft-ietf-nfsv4-acls-00.  
> Then I will
> propose an alternative design which is more correct than  
> introducing DENY
> entries to mask permissions. (As a bonus, it is easier to  
> implement. too.)
>
>> On a UNIX system that supports NFSv4 ACLs natively, I think we  
>> should try
>> to accept as wide a range of NFSv4 ACLs as possible, but we must  
>> make sure
>> that we can preserve POSIX semantics. In particular, this means  
>> that ACLs
>> may contain ACEs for users other than OWNER@, GROUP@, and  
>> EVERYONE@, and
>> that chmod(2) must continue to provide the same kinds of  
>> guarantees as
>> without NFSv4 ACLs.
>>
>> I am assuming here that NFSv4 ACLs shall be an additional rather  
>> than an
>> alternate file access control mechanism in the POSIX sense:  
>> Alternate file
>> access control mechanisms must ``be enabled only by explicit user  
>> action,
>> on a per-file basis by the file owner or a user with the appropriate
>> privilege'', and must ``be disabled for a file after the file  
>> permission
>> bits are changed for that file with chmod( )'' according to POSIX.  
>> In other
>> words, newly created files or directories would have alternate  
>> file access
>> control mechanisms disabled. This would render NFSv4 ACLs essentially
>> useless for UNIX processes, because they would almost always be  
>> disabled,
>> and would only work for remote processes until a POSIX process  
>> chmods a
>> file or creates a directory, which wouldn't get us very far.
>
> As Sam pointed out, a subset of NFSv4 ACLs maps to an additional  
> file access
> control mechanism, while the rest goes beyond that, and therefore  
> is an
> alternate file access control mechanism.

Yes -- ALLOW ACEs are alternate file access control, and DENY ACEs  
are additional file access control.

> It is important to understand how POSIX defines additional file  
> access control
> mechanisms:
>
> [] 3.4 Additional File Access Control Mechanism
> [] An implementation-defined mechanism that is layered upon the  
> access control
> []  mechanisms defined here, but which do not grant permissions  
> beyond those
> []  defined herein, although they may further restrict them.
>
> In other words, when a file has just been created and after chmod,  
> the file
> mode permission bits define an upper bound to the permissions  
> granted to
> anyone on the system, and nobody has additional permissions.  
> Additional
> permissions (as an alternate file access control mechanism) may be
> enabled explicitly, but the next chmod must disable them again.

The use of the word "Additional" is confusing in the above  
sentence.  :-)  I think you mean "more", or similar, but "Additional"  
has a very specific meaning which (I think) isn't what you mean.

> We can classify the permissions that NFSv4 ACLs grant into  
> additional and
> alternate mechanisms as follows: everything covered by the POSIX
> read/write/execute permissions (such as ACE4_READ_DATA, but also
> ACE4_APPEND_DATA) is additional, while everything beyond that (such as
> ACE4_WRITE_OWNER) is alternate.

Note well: this is quite different from draft-ietf-nfsv4- 
minorversion1-03.txt, i.e. this is an alternate proposal.

> Under this definition, all NFSv4 ACLs that
> grant no more than ACE4_READ_DATA, ACE4_LIST_DIRECTORY,  
> ACE4_WRITE_DATA,
> ACE4_ADD_FILE, ACE4_APPEND_DATA, ACE4_ADD_SUBDIRECTORY,
> ACE4_READ_NAMED_ATTRS, ACE4_WRITE_NAMED_ATTRS, ACE4_EXECUTE,
> ACE4_READ_ATTRIBUTES, ACE4_WRITE_ATTRIBUTES, ACE4_READ_ACL, and
> ACE4_SYNCHRONIZE would count as additional access control  
> mechanisms. All
> others with ACE4_WRITE_ACL, ACE4_WRITE_OWNER, ACE4_DELETE_CHILD, and
> ACE4_DELETE are alternate.

I don't understand what is gained by this designation of additional  
access control mechanisms.  If you really say that this ACL:

OWNER@:read_data:allow
friend@your.com:read_data:allow

is additional file access control, then what is the mode on such a  
file?  Unless the mode says "group can read", then friend@your.com  
wouldn't be able to read, if the ACL is additional file access  
control.  What if you want friend@your.com to be able to read, but  
you don't want the file's owning group to read?

> As said already, the POSIX file mode permission bits define the  
> permissions of
> three classes: owner, group, and other. An additional file access  
> control
> mechanism may only further restrict the permissions granted to  
> those classes.

> To map NFSv4 ACLs to an additional file access control mechanism,

>  - we must map each NFSv4 ACL entry to exactly one of the three  
> classes.
>
>  - we must ensure that the ACL does not grant any permissions that  
> go beyond
>    the class permissions after a chmod or create.

Additional File Access Control must not grant beyond the class  
permissions *ever*, not just after create or chmod.

>  - in particular, we must ensure that the ACL grants no "alternate"
>    permissions after a chmod or create.

I don't understand this; you began this section with "To map NFSv4  
ACLs to an additional...", but here, you seem to be describing ACLs  
as an alternate file access control mechanism.

> We are free to provide mechanisms by which more permissions may be  
> enabled by
> explicit user action, on a per-file basis by the file owner or a  
> user with
> the appropriate privilege, according to POSIX.

>
> The POSIX definitions of the three file permission classes are:
>
> [] 3.173 File Owner Class
> [] The property of a file indicating access permissions for a  
> process related
> [] to the user identification of a process. A process is in the  
> file owner
> [] class of a file if the effective user ID of the process matches  
> the user ID
> [] of the file.
>
> [] 3.166 File Group Class
> [] The property of a file indicating access permissions for a process
> [] related to the group identification of a process. A process is in
> [] the file group class of a file if the process is not in the file  
> owner
> [] class and if the effective group ID or one of the supplementary  
> group
> [] IDs of the process matches the group ID associated with the  
> file. Other
> [] members of the class may be implementation-defined.
>
> [] 3.172 File Other Class
> [] The property of a file indicating access permissions for a  
> process related
> [] to the user and group identification of a process. A process is  
> in the file
> [] other class of a file if the process is not in the file owner  
> class or file
> [] group class.
>
> The key fact in these definitions is that an implementation may define
> additional members of the File Group Class, while the other classes  
> are not
> extensible.
>
> Under this definition, we end up with the following mapping:
>
>  - OWNER@ entries are in the File Owner Class,
>  - EVERYONE@ entries are in the File Other Class,

No, I don't think EVERYONE@ is in the File Other Class.  Given this ACL:

EVERYONE@:read_data:deny
OWNER@:read_data:allow

the owner would NOT be able to read.  In other words, file owner  
class and file group class are also affected by EVERYONE@ ACEs.

>  - every other entry is in the File Group Class(*).

including EVERYONE@.  ;-)

>  (*) User entries for the user who is the current file owner are a  
> special
>      case: due to how the NFSv4 ACL permission check algorithm is  
> specified,
>      I believe that they should be put in the OWNER@ class.

The current minorversion1 draft has a similar design constraint.

>> Note that this definition is in line with POSIX 1003.1e draft 17  
>> [2], while
>> it conflicts with the IETF NFS Version 4 ACLs draft [1], which  
>> associates
>> only GROUP@ entries with the group file mode permission bits in  
>> section
>> 5.1. The relevant text of IETF NFS Version 4 ACLs draft [1] is  
>> also found
>> in NFSv4 Minor Version 1 [4].
>
> Section 5.1 of [1] needs to be fixed: we must set the permission  
> bits so that
> they are a superset of the permissions of all the entries in the  
> respective
> class. (We cannot represent permissions that are not supersets of
> POSIX read, write, execute in the class, but that is not a problem,  
> as we will
> see later.)

We must do so carefully.  I'm not convinced that a superset is the  
best way to go, but we should talk about this later.

> Non-monotonic permissions
> =========================
>
> Note that with arbitrary NFSV4 ACLs, the permissions granted to a  
> process from
> multiple ACL entries will accumulate. This means that permissions  
> across
> multiple classes may accumulate as well. This can be prevented with  
> DENY
> entries in the ACL, e.g.,
>
> 	OWNER@:mask1::ALLOW
> 	OWNER@:^mask1::DENY
> 	user@domain:mask2::ALLOW
> 	group@domain:mask3:ACE4_IDENTIFIER_GROUP:ALLOW
> 	user@domain:^mask2::DENY
> 	group@domain:^mask3:ACE4_IDENTIFIER_GROUP:DENY
> 	EVERYONE:mask4::ALLOW
>
> This means that we will not have to deal with this special case  
> when computing
> the file mode permission bits, and we can achieve consistency by  
> forcing ACLs
> to be "well structured".

Yuck!  I'm glad you're not proposing this as a general NFSv4 ACL  
model.  :-)

> We could also leave this as an implementation consideration: ACLs  
> which are
> not "well structured" in the above sense will grant permissions  
> that go
> beyond what an additional access control mechanism may grant *only*  
> for
> non-monotonic file mode permission bits. With non-monotonic I mean  
> file mode
> permission bits which grant more permissions to the group class  
> than to the
> owner class, or more permissions to the other class than to the  
> group class.

I'm sorry, I just don't follow that paragraph.

>> We want chmod(2) to be non-destructive, so that a chmod to a more
>> restrictive mode and back to the original mode will leave the file  
>> with the
>> same permissions as before the changes.
>>
>> [...]
>>
>> POSIX ACLs have solved the non-destructiveness problem by  
>> introducing a
>> mask ACL entry: the mask entry applies to all group class entries,  
>> and
>> defines an upper bound to the permissions those entries may grant.  
>> POSIX
>> ACLs only have ACL entries that allow permissions, and only  
>> specify READ,
>> WRITE, and EXECUTE permissions. Therefore, the owner class and  
>> other class
>> permissions are the permissions granted to the owner and to others,
>> respectively. (Note the difference between these others and NFSv4's
>> EVERYONE@ special identifier).
>>
>> The mask concept is not part of NFSv4 ACLs. Marius A. Eriksen and  
>> others
>> have proposed to emulate the POSIX ACL mask entry by prepending (with
>> exception of OWNER@ and EVERYONE@ ACEs) each ALLOW ACE with a DENY  
>> ACE for
>> the same user, group, or special identifier as in the ALLOW ACE. The
>> permissions in the DENY ACE are set so that the entry denies the
>> permissions not granted by the mask.
>
> Internet draft-ietf-nfsv4-acls-00.txt [1] uses the same mechanism  
> to implement
> masking.
>
>> Unless we accept a very specific form of NFSv4 ACLs only (which would
>> contradict the goal stated at the top of this message, and which  
>> would mean
>> that interoperability with anything but POSIX ACLs would become  
>> difficult),
>> there is no easy way to tell DENY entries introduced to emulate  
>> the mask
>> from DENY entries added by hand.

I would refute this; see below.

>> This has two potential consequences:
>>
>>  - First, if we fail to identify such a mask-emulation DENY entry,  
>> we may
>> end up inserting another such entry. We might end up doing so  
>> repeatedly.

But we will not ever fail to identify such a mask-emulation DENY  
entry, when it is one that was created by a previous chmod.  Only in  
a degenerate case of modify-acl-carefully, chmod, modify-acl- 
carefully, chmod, etc., would you get a growing ACL problem.

>>  - Second, we may take a user-provided DENY entry for a mask- 
>> emulation DENY
>> entry, and clear mask bits from that entry. This would contradict the
>> user's intention. So the approach of inserting mask-emulation DENY  
>> entries
>> is not good enough in general.

A user-provided DENY entry would have to fit into a very specific and  
somewhat nonsensical form in order to be misidentified.  Here's an  
example:

samf@sun.com:read_data:deny
samf@sun.com:read_data:allow

If a "chmod 444" were done, the deny ACE above would be modified.   
Any other cases of chmod modifying a user-provided ACE would have to  
be essentially the same as the above example.  I think that that's an  
acceptable situation.

>> (Mapping between NFSv4 and POSIX ACLs does
>> not have this problem, because POSIX ACLs don't have DENY ACEs.)

> Therefore, the mechanism described in section 5.3 is not suitable  
> for our
> purposes, and we need to replace it with something better.

I don't agree that 5.3 is not suitable, but I would love to see  
something better.

>> In my opinion, there are two possible solutions for this problem:  
>> we can
>> (1) devise a special kind of NFSv4 ACL entry that we will  
>> recognize as mask
>> entry, or (2) give the owner/group/other class permission bits higher
>> priority than the ACL entries, and only allow permissions that are  
>> allowed
>> by both the ACEs and their associated classes.

Yikes -- I don't like either of the above solutions; let's look at  
the third...

> A third option exists as well which fits in very well with POSIX  
> and can be
> implemented in NFSv4 in a backward compatible way.
>
> Alternative Proposal
> ====================
>
> Instead of adding DENY entries to the ACL for the purpose of  
> masking, attach
> three optional attributes to each file: owner_class_mask,  
> group_class_mask,
> and other_class_mask. When those attributes are present, they  
> define which
> permissions in an ACE are effective.
>
> Each ACE is is restricted by one of these mask attributes in each  
> access
> check:
>
>  - OWNER@ entries and entries for the user@domain that currently  
> owns the file
>    are restricted by owner_class_mask.
>
>  - EVERYONE@ entries are restricted by other_class_mask.
>
>  - All other entries are restricted by group_class_mask.
>
> The effective permissions are computed as the bitwise and (&) of  
> the ACE mask
> and the associated class_mask attribute.

I take it you mean that "the effective access mask bits for ACEs of  
type ALLOW"?

> When doing a chmod(2) or when applying a create mask, the  
> owner_class_mask,
> group_class_mask, and other_class_mask attributes are modified  
> according to
> the owner class, group class, and other class permissions of the mode
> parameter as follows:
>
>  - The POSIX read permission implies the ACE4_READ_DATA,  
> ACE4_READ_ATTRIBUTES,
> ACE4_READ_ACL, and ACE4_SYNCHRONIZE bitmask flags.
>
>  - The POSIX write permission implies the ACE4_WRITE_DATA,  
> ACE4_APPEND_DATA,
> ACE4_WRITE_ATTRIBUTES, ACE4_DELETE_CHILD, and ACE4_SYNCHRONIZE  
> bitmask flags.

I'm not sure I agree about ACE4_WRITE_ATTRIBUTES, but that's a minor  
detail.

>  - The POSIX execute permission implies the ACE4_EXECUTE mask.

> This saves us from bloating ACLs with DENY entries, is more  
> efficient when
> doing a chmod, and also saves us from destroying permissions in  
> user provided
> DENY entries.

Yes, but at the cost of adding new file attributes...  Don't get me  
wrong, I do see merit in this proposal, but I don't know if it'll be  
acceptable.

> When an ACL is set, then set all mask attributes to the values  
> provided in the
> same SETATTR operation, and set the remaining mask attributes to  
> the union of
> all ALLOW ACL entries in the ACL that the class applies to.

This doesn't take the ordering of the ACL into account; is this your  
intention?  So

GROUP@:read_data/write_data:DENY
GROUP@:read_data/write_data:ALLOW

would result in a group_class_mask of read_data|write_data, right?   
(I'm not saying it's wrong, I'm just making sure I understand.)

> Without any further changes, NFSv4 clients not aware of the three  
> optional
> attributes would not be aware of the restrictions imposed by those  
> masks when
> querying for the ACL. This would create an interoperability  
> problem, and
> possible security holes. To solve this problem, we can extend the  
> GETATTR
> operation as follows:
>
> When a client requests the ACL attribute, check if it also requests  
> one or
> more of the three optional owner_class_mask, group_class_mask, or
> other_class_mask attributes. If it does, then send the requested  
> attributes
> as they are. If the client requests only the ACL without any of the  
> masks,
> return an ACL with only effective mask flags set, and with all  
> other flags
> removed.

I assume you mean in the ALLOW ACEs only, right?

> Alternate permissions in the ACL can be enabled by either setting  
> an ACL
> without providing full mask entries, or by setting the appropriate  
> bit(s) in
> the corresponding mask entry or entries.

Yes, I think I understand.

> When comparing POSIX ACLs and the NFSv4 ACL + mask attributes as  
> proposed
> here, one obvious difference is that POSIX ACLs have only one mask  
> entry,
> while I propose three mask entries here. The reason for this is  
> that POSIX
> ACLs can at most grant read, write, and execute permissions, and so  
> with
> POSIX ACLs, the File Owner Class permissions are always identical  
> to the
> permissions granted to the owner, and the File Other Class  
> permissions are
> always identical to the permissions granted to others. With NFSv4  
> ACLs,
> OWNER@ and EVERYONE@ entries may grant additional permissions that  
> go beyond
> what POSIX read, write, and execute can grant, and we need a  
> mechanism so
> that those alternate permissions can be turned off by chmod and  
> during file
> create without destroying the permissions.

Given that EVERYONE@ is not equivalent to the POSIX "other" class, it  
could be trimmed down to two.

> I would appreciate if you could take this alternative proposal into
> consideration when deciding how to proceed with NFSv4 Minor
> Version 1 at next week's IETF 66 meeting.

This proposal certainly has its merits.  I have doubts about the  
feasibility of adding two or three new file attributes, and new as- 
yet-unimplemented semantics, into the minorversion1 draft.  I have  
doubts about how this would be implemented on a Windows-based server.

The current design specified in draft-ietf-nfsv4-minorversion1-03.txt  
has implementation experience -- it's released in Solaris 10 update  
3, a shipping product.  It meets strict POSIX requirements for those  
implementations that choose to conform to POSIX.  I believe it's  
fully implementable on a Windows-based server.

I too hope that this can be discussed at IETF 66.

- Sam

>
>
> Thanks and best regards,
> Andreas
>
>> REFERENCES
>>
>> [1] Sam Falkner et al.: NFS Version 4 ACLs, draft-ietf-nfsv4- 
>> acls-00.txt
>>
>> [2] POSIX 1003.1e/2c draft 17 (withdrawn),
>> http://wt.xpilot.org/publications/posix.1e
>>
>> [3] Marius Aamodt Eriksen et al.: Mapping Between NFSv4 and Posix  
>> Draft
>> ACLs, draft-ietf-nfsv4-acl-mapping-04.txt
>>
>> [4] Spencer Shepler (editor): NFSv4 Minor Version 1,
>> draft-ietf-nfsv4-minorversion1-03.txt
>
> -- 
> Andreas Gruenbacher <agruen@suse.de>
> Novell / SUSE Labs


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Lisa Week]

[-- Attachment #1.1: Type: text/plain, Size: 24876 bytes --]

Hi Andreas,

I have a couple additional questions and comments.  See those inline...

Thanks,
Lisa

On Jul 7, 2006, at 9:45 PM, Sam Falkner wrote:

> On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:
>
>> On Monday, 3. July 2006 23:10, Andreas Gruenbacher wrote:
>>> Hello,
>>>
>>> I have been thinking about the problems of interaction between  
>>> NFSv4 ACLs
>>> and POSIX, and particularly about the issue of masking  
>>> permissions through
>>> chmod and after creating files or directories.
>>
>> Here is a follow-up after some personal feedback from Sam. I  
>> believe that
>> draft-ietf-nfsv4-acls-00 is not ready to become part of the NFSv4  
>> Minor
>> Version 1 RFC: some assumptions are not correct from a POSIX point  
>> of view,
>> and the way how chmod and file create modes are applied to NFSv4  
>> ACLs is weak
>> and not guaranteed to be correct.
>
> I disagree -- see below.
>
>> I will first try to clarify some of the points I tried to make in  
>> the previous
>> posting and point out deficiencies in draft-ietf-nfsv4-acls-00.  
>> Then I will
>> propose an alternative design which is more correct than  
>> introducing DENY
>> entries to mask permissions. (As a bonus, it is easier to  
>> implement. too.)
>>
>>> On a UNIX system that supports NFSv4 ACLs natively, I think we  
>>> should try
>>> to accept as wide a range of NFSv4 ACLs as possible, but we must  
>>> make sure
>>> that we can preserve POSIX semantics. In particular, this means  
>>> that ACLs
>>> may contain ACEs for users other than OWNER@, GROUP@, and  
>>> EVERYONE@, and
>>> that chmod(2) must continue to provide the same kinds of  
>>> guarantees as
>>> without NFSv4 ACLs.
>>>
>>> I am assuming here that NFSv4 ACLs shall be an additional rather  
>>> than an
>>> alternate file access control mechanism in the POSIX sense:  
>>> Alternate file
>>> access control mechanisms must ``be enabled only by explicit user  
>>> action,
>>> on a per-file basis by the file owner or a user with the appropriate
>>> privilege'', and must ``be disabled for a file after the file  
>>> permission
>>> bits are changed for that file with chmod( )'' according to  
>>> POSIX. In other
>>> words, newly created files or directories would have alternate  
>>> file access
>>> control mechanisms disabled. This would render NFSv4 ACLs  
>>> essentially
>>> useless for UNIX processes, because they would almost always be  
>>> disabled,
>>> and would only work for remote processes until a POSIX process  
>>> chmods a
>>> file or creates a directory, which wouldn't get us very far.
>>
>> As Sam pointed out, a subset of NFSv4 ACLs maps to an additional  
>> file access
>> control mechanism, while the rest goes beyond that, and therefore  
>> is an
>> alternate file access control mechanism.
>
> Yes -- ALLOW ACEs are alternate file access control, and DENY ACEs  
> are additional file access control.
>
>> It is important to understand how POSIX defines additional file  
>> access control
>> mechanisms:
>>
>> [] 3.4 Additional File Access Control Mechanism
>> [] An implementation-defined mechanism that is layered upon the  
>> access control
>> []  mechanisms defined here, but which do not grant permissions  
>> beyond those
>> []  defined herein, although they may further restrict them.
>>
>> In other words, when a file has just been created and after chmod,  
>> the file
>> mode permission bits define an upper bound to the permissions  
>> granted to
>> anyone on the system, and nobody has additional permissions.  
>> Additional
>> permissions (as an alternate file access control mechanism) may be
>> enabled explicitly, but the next chmod must disable them again.
>
> The use of the word "Additional" is confusing in the above  
> sentence.  :-)  I think you mean "more", or similar, but  
> "Additional" has a very specific meaning which (I think) isn't what  
> you mean.
>
>> We can classify the permissions that NFSv4 ACLs grant into  
>> additional and
>> alternate mechanisms as follows: everything covered by the POSIX
>> read/write/execute permissions (such as ACE4_READ_DATA, but also
>> ACE4_APPEND_DATA) is additional, while everything beyond that  
>> (such as
>> ACE4_WRITE_OWNER) is alternate.
>
> Note well: this is quite different from draft-ietf-nfsv4- 
> minorversion1-03.txt, i.e. this is an alternate proposal.
>
>> Under this definition, all NFSv4 ACLs that
>> grant no more than ACE4_READ_DATA, ACE4_LIST_DIRECTORY,  
>> ACE4_WRITE_DATA,
>> ACE4_ADD_FILE, ACE4_APPEND_DATA, ACE4_ADD_SUBDIRECTORY,
>> ACE4_READ_NAMED_ATTRS, ACE4_WRITE_NAMED_ATTRS, ACE4_EXECUTE,
>> ACE4_READ_ATTRIBUTES, ACE4_WRITE_ATTRIBUTES, ACE4_READ_ACL, and
>> ACE4_SYNCHRONIZE would count as additional access control  
>> mechanisms. All
>> others with ACE4_WRITE_ACL, ACE4_WRITE_OWNER, ACE4_DELETE_CHILD, and
>> ACE4_DELETE are alternate.
>
> I don't understand what is gained by this designation of additional  
> access control mechanisms.  If you really say that this ACL:
>
> OWNER@:read_data:allow
> friend@your.com:read_data:allow
>
> is additional file access control, then what is the mode on such a  
> file?  Unless the mode says "group can read", then friend@your.com  
> wouldn't be able to read, if the ACL is additional file access  
> control.  What if you want friend@your.com to be able to read, but  
> you don't want the file's owning group to read?

1.) If ACEs with ACE4_WRITE_ACL, ACE4_WRITE_OWNER, ACE4_DELETE_CHILD  
and ACE4_DELETE are alternate access control mechanisms, what will  
happen to ACEs with these access mask bits set upon chmod of the file?

For example, if we have the following ACL:
     lisa@sun.com:ACE4_WRITE_ACL:deny

		or even

     lisa@sun.com:ACE4_WRITE_OWNER:allow

Upon chmod we would have to disable them (however an implementation  
chooses to) and effectively remove it.

The thing that I have a problem with here is the fact that the  
changing of the file permission bits will affect what access has been  
defined in the ACL for things such as ACE4_WRITE_OWNER,  
ACE4_WRITE_ACL, etc.  A user setting the file permission bits is not  
saying anything about what they want to be done with any ACEs that  
include the ACE4_WRITE_OWNER mask bit.  Why would we want to mess  
with them?

2.) So, what if an ACE contained a mixture of the access mask bits  
that are alternate and additional?

Would we allow having ACE4_READ_DATA and ACE4_WRITE_ACL in the same  
ACE?  What would happen to an ACE such as this upon chmod?

>
>> As said already, the POSIX file mode permission bits define the  
>> permissions of
>> three classes: owner, group, and other. An additional file access  
>> control
>> mechanism may only further restrict the permissions granted to  
>> those classes.
>
>> To map NFSv4 ACLs to an additional file access control mechanism,
>
>>  - we must map each NFSv4 ACL entry to exactly one of the three  
>> classes.
>>
>>  - we must ensure that the ACL does not grant any permissions that  
>> go beyond
>>    the class permissions after a chmod or create.
>
> Additional File Access Control must not grant beyond the class  
> permissions *ever*, not just after create or chmod.
>
>>  - in particular, we must ensure that the ACL grants no "alternate"
>>    permissions after a chmod or create.
>
> I don't understand this; you began this section with "To map NFSv4  
> ACLs to an additional...", but here, you seem to be describing ACLs  
> as an alternate file access control mechanism.
>
>> We are free to provide mechanisms by which more permissions may be  
>> enabled by
>> explicit user action, on a per-file basis by the file owner or a  
>> user with
>> the appropriate privilege, according to POSIX.
>
>>
>> The POSIX definitions of the three file permission classes are:
>>
>> [] 3.173 File Owner Class
>> [] The property of a file indicating access permissions for a  
>> process related
>> [] to the user identification of a process. A process is in the  
>> file owner
>> [] class of a file if the effective user ID of the process matches  
>> the user ID
>> [] of the file.
>>
>> [] 3.166 File Group Class
>> [] The property of a file indicating access permissions for a process
>> [] related to the group identification of a process. A process is in
>> [] the file group class of a file if the process is not in the  
>> file owner
>> [] class and if the effective group ID or one of the supplementary  
>> group
>> [] IDs of the process matches the group ID associated with the  
>> file. Other
>> [] members of the class may be implementation-defined.
>>
>> [] 3.172 File Other Class
>> [] The property of a file indicating access permissions for a  
>> process related
>> [] to the user and group identification of a process. A process is  
>> in the file
>> [] other class of a file if the process is not in the file owner  
>> class or file
>> [] group class.
>>
>> The key fact in these definitions is that an implementation may  
>> define
>> additional members of the File Group Class, while the other  
>> classes are not
>> extensible.
>>
>> Under this definition, we end up with the following mapping:
>>
>>  - OWNER@ entries are in the File Owner Class,
>>  - EVERYONE@ entries are in the File Other Class,
>
> No, I don't think EVERYONE@ is in the File Other Class.  Given this  
> ACL:
>
> EVERYONE@:read_data:deny
> OWNER@:read_data:allow
>
> the owner would NOT be able to read.  In other words, file owner  
> class and file group class are also affected by EVERYONE@ ACEs.

I'll restate it because it is important: EVERYONE@ is not equivalent  
to the File Other Class.  I believe the original intention was to  
have it be equivalent to one the Windows "well known sid":   http:// 
msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/ 
security/well_known_sid_type.asp


Really with NFSv4 ACLs, the only way we have the equivalent of a File  
Other Class is if the EVERYONE@ entries come at the end of the ACL.   
Such as this:

      owner@:execute:deny
      owner@:read_data/write_data/append_data/write_xattr/ 
write_attributes
          /write_acl/write_owner:allow
      group@:write_data/append_data/execute:deny
      group@:read_data:allow
      everyone@:write_data/append_data/write_xattr/execute/ 
write_attributes
          /write_acl/write_owner:deny
      everyone@:read_data/read_xattr/read_attributes/read_acl/ 
synchronize
          :allow


>
>>  - every other entry is in the File Group Class(*).
>
> including EVERYONE@.  ;-)
>
>>  (*) User entries for the user who is the current file owner are a  
>> special
>>      case: due to how the NFSv4 ACL permission check algorithm is  
>> specified,
>>      I believe that they should be put in the OWNER@ class.
>
> The current minorversion1 draft has a similar design constraint.
>
>>> Note that this definition is in line with POSIX 1003.1e draft 17  
>>> [2], while
>>> it conflicts with the IETF NFS Version 4 ACLs draft [1], which  
>>> associates
>>> only GROUP@ entries with the group file mode permission bits in  
>>> section
>>> 5.1. The relevant text of IETF NFS Version 4 ACLs draft [1] is  
>>> also found
>>> in NFSv4 Minor Version 1 [4].
>>
>> Section 5.1 of [1] needs to be fixed: we must set the permission  
>> bits so that
>> they are a superset of the permissions of all the entries in the  
>> respective
>> class. (We cannot represent permissions that are not supersets of
>> POSIX read, write, execute in the class, but that is not a  
>> problem, as we will
>> see later.)
>
> We must do so carefully.  I'm not convinced that a superset is the  
> best way to go, but we should talk about this later.
>
>> Non-monotonic permissions
>> =========================
>>
>> Note that with arbitrary NFSV4 ACLs, the permissions granted to a  
>> process from
>> multiple ACL entries will accumulate. This means that permissions  
>> across
>> multiple classes may accumulate as well. This can be prevented  
>> with DENY
>> entries in the ACL, e.g.,
>>
>> 	OWNER@:mask1::ALLOW
>> 	OWNER@:^mask1::DENY
>> 	user@domain:mask2::ALLOW
>> 	group@domain:mask3:ACE4_IDENTIFIER_GROUP:ALLOW
>> 	user@domain:^mask2::DENY
>> 	group@domain:^mask3:ACE4_IDENTIFIER_GROUP:DENY
>> 	EVERYONE:mask4::ALLOW
>>
>> This means that we will not have to deal with this special case  
>> when computing
>> the file mode permission bits, and we can achieve consistency by  
>> forcing ACLs
>> to be "well structured".
>
> Yuck!  I'm glad you're not proposing this as a general NFSv4 ACL  
> model.  :-)
>
>> We could also leave this as an implementation consideration: ACLs  
>> which are
>> not "well structured" in the above sense will grant permissions  
>> that go
>> beyond what an additional access control mechanism may grant  
>> *only* for
>> non-monotonic file mode permission bits. With non-monotonic I mean  
>> file mode
>> permission bits which grant more permissions to the group class  
>> than to the
>> owner class, or more permissions to the other class than to the  
>> group class.
>
> I'm sorry, I just don't follow that paragraph.
>
>>> We want chmod(2) to be non-destructive, so that a chmod to a more
>>> restrictive mode and back to the original mode will leave the  
>>> file with the
>>> same permissions as before the changes.
>>>
>>> [...]
>>>
>>> POSIX ACLs have solved the non-destructiveness problem by  
>>> introducing a
>>> mask ACL entry: the mask entry applies to all group class  
>>> entries, and
>>> defines an upper bound to the permissions those entries may  
>>> grant. POSIX
>>> ACLs only have ACL entries that allow permissions, and only  
>>> specify READ,
>>> WRITE, and EXECUTE permissions. Therefore, the owner class and  
>>> other class
>>> permissions are the permissions granted to the owner and to others,
>>> respectively. (Note the difference between these others and NFSv4's
>>> EVERYONE@ special identifier).
>>>
>>> The mask concept is not part of NFSv4 ACLs. Marius A. Eriksen and  
>>> others
>>> have proposed to emulate the POSIX ACL mask entry by prepending  
>>> (with
>>> exception of OWNER@ and EVERYONE@ ACEs) each ALLOW ACE with a  
>>> DENY ACE for
>>> the same user, group, or special identifier as in the ALLOW ACE. The
>>> permissions in the DENY ACE are set so that the entry denies the
>>> permissions not granted by the mask.
>>
>> Internet draft-ietf-nfsv4-acls-00.txt [1] uses the same mechanism  
>> to implement
>> masking.
>>
>>> Unless we accept a very specific form of NFSv4 ACLs only (which  
>>> would
>>> contradict the goal stated at the top of this message, and which  
>>> would mean
>>> that interoperability with anything but POSIX ACLs would become  
>>> difficult),
>>> there is no easy way to tell DENY entries introduced to emulate  
>>> the mask
>>> from DENY entries added by hand.
>
> I would refute this; see below.
>
>>> This has two potential consequences:
>>>
>>>  - First, if we fail to identify such a mask-emulation DENY  
>>> entry, we may
>>> end up inserting another such entry. We might end up doing so  
>>> repeatedly.
>
> But we will not ever fail to identify such a mask-emulation DENY  
> entry, when it is one that was created by a previous chmod.  Only  
> in a degenerate case of modify-acl-carefully, chmod, modify-acl- 
> carefully, chmod, etc., would you get a growing ACL problem.
>
>>>  - Second, we may take a user-provided DENY entry for a mask- 
>>> emulation DENY
>>> entry, and clear mask bits from that entry. This would contradict  
>>> the
>>> user's intention. So the approach of inserting mask-emulation  
>>> DENY entries
>>> is not good enough in general.
>
> A user-provided DENY entry would have to fit into a very specific  
> and somewhat nonsensical form in order to be misidentified.  Here's  
> an example:
>
> samf@sun.com:read_data:deny
> samf@sun.com:read_data:allow
>
> If a "chmod 444" were done, the deny ACE above would be modified.   
> Any other cases of chmod modifying a user-provided ACE would have  
> to be essentially the same as the above example.  I think that  
> that's an acceptable situation.
>
>>> (Mapping between NFSv4 and POSIX ACLs does
>>> not have this problem, because POSIX ACLs don't have DENY ACEs.)
>
>> Therefore, the mechanism described in section 5.3 is not suitable  
>> for our
>> purposes, and we need to replace it with something better.
>
> I don't agree that 5.3 is not suitable, but I would love to see  
> something better.
>
>>> In my opinion, there are two possible solutions for this problem:  
>>> we can
>>> (1) devise a special kind of NFSv4 ACL entry that we will  
>>> recognize as mask
>>> entry, or (2) give the owner/group/other class permission bits  
>>> higher
>>> priority than the ACL entries, and only allow permissions that  
>>> are allowed
>>> by both the ACEs and their associated classes.
>
> Yikes -- I don't like either of the above solutions; let's look at  
> the third...
>
>> A third option exists as well which fits in very well with POSIX  
>> and can be
>> implemented in NFSv4 in a backward compatible way.
>>
>> Alternative Proposal
>> ====================
>>
>> Instead of adding DENY entries to the ACL for the purpose of  
>> masking, attach
>> three optional attributes to each file: owner_class_mask,  
>> group_class_mask,
>> and other_class_mask. When those attributes are present, they  
>> define which
>> permissions in an ACE are effective.
>>
>> Each ACE is is restricted by one of these mask attributes in each  
>> access
>> check:
>>
>>  - OWNER@ entries and entries for the user@domain that currently  
>> owns the file
>>    are restricted by owner_class_mask.
>>
>>  - EVERYONE@ entries are restricted by other_class_mask.

Again, EVERYONE@ is not equivalent to the File Other Class.   
Depending on where an ACE pertaining to EVERYONE@ is in the ACL, it  
could even refer to the owner and the owning group.

>>
>>  - All other entries are restricted by group_class_mask.
>>
>> The effective permissions are computed as the bitwise and (&) of  
>> the ACE mask
>> and the associated class_mask attribute.
>
> I take it you mean that "the effective access mask bits for ACEs of  
> type ALLOW"?
>
>> When doing a chmod(2) or when applying a create mask, the  
>> owner_class_mask,
>> group_class_mask, and other_class_mask attributes are modified  
>> according to
>> the owner class, group class, and other class permissions of the mode
>> parameter as follows:
>>
>>  - The POSIX read permission implies the ACE4_READ_DATA,  
>> ACE4_READ_ATTRIBUTES,
>> ACE4_READ_ACL, and ACE4_SYNCHRONIZE bitmask flags.
>>
>>  - The POSIX write permission implies the ACE4_WRITE_DATA,  
>> ACE4_APPEND_DATA,
>> ACE4_WRITE_ATTRIBUTES, ACE4_DELETE_CHILD, and ACE4_SYNCHRONIZE  
>> bitmask flags.
>
> I'm not sure I agree about ACE4_WRITE_ATTRIBUTES, but that's a  
> minor detail.

Yes, as [4] says, ACE4_WRITE_ATTRIBUTES is the "Permission to change  
the times associated with a file or directory to an arbitrary  
value."  Having that included in the POSIX write permission would not  
be correct, but as Sam said, that is minor.

>
>>  - The POSIX execute permission implies the ACE4_EXECUTE mask.
>
>> This saves us from bloating ACLs with DENY entries, is more  
>> efficient when
>> doing a chmod, and also saves us from destroying permissions in  
>> user provided
>> DENY entries.
>
> Yes, but at the cost of adding new file attributes...  Don't get me  
> wrong, I do see merit in this proposal, but I don't know if it'll  
> be acceptable.
>
>> When an ACL is set, then set all mask attributes to the values  
>> provided in the
>> same SETATTR operation, and set the remaining mask attributes to  
>> the union of
>> all ALLOW ACL entries in the ACL that the class applies to.
>
> This doesn't take the ordering of the ACL into account; is this  
> your intention?  So
>
> GROUP@:read_data/write_data:DENY
> GROUP@:read_data/write_data:ALLOW
>
> would result in a group_class_mask of read_data|write_data, right?   
> (I'm not saying it's wrong, I'm just making sure I understand.)
>
>> Without any further changes, NFSv4 clients not aware of the three  
>> optional
>> attributes would not be aware of the restrictions imposed by those  
>> masks when
>> querying for the ACL. This would create an interoperability  
>> problem, and
>> possible security holes. To solve this problem, we can extend the  
>> GETATTR
>> operation as follows:
>>
>> When a client requests the ACL attribute, check if it also  
>> requests one or
>> more of the three optional owner_class_mask, group_class_mask, or
>> other_class_mask attributes. If it does, then send the requested  
>> attributes
>> as they are. If the client requests only the ACL without any of  
>> the masks,
>> return an ACL with only effective mask flags set, and with all  
>> other flags
>> removed.
>
> I assume you mean in the ALLOW ACEs only, right?
>
>> Alternate permissions in the ACL can be enabled by either setting  
>> an ACL
>> without providing full mask entries, or by setting the appropriate  
>> bit(s) in
>> the corresponding mask entry or entries.
>
> Yes, I think I understand.

Sorry, but I don't think I understand.  Andreas, what do you mean by  
"Alternate" permissions in that sentence?  It is unclear to me as to  
what happens to the access mask bits outside of the following:   
(collectively, these are the access mask bits that make up the POSIX  
read, write and execute permissions)
ACE4_READ_DATA, ACE4_READ_ATTRIBUTES, ACE4_READ_ACL, ACE4_SYNCHRONIZE  
ACE4_WRITE_DATA, ACE4_APPEND_DATA, ACE4_WRITE_ATTRIBUTES,  
ACE4_DELETE_CHILD and ACE4_EXECUTE

The remaining ones are:
ACE4_WRITE_ACL, ACE4_WRITE_OWNER, ACE4_DELETE, ACE4_READ_NAMED_ATTRS  
and ACE4_WRITE_NAMED_ATTRS

Are these "remaining ones" also given representation in the masks?   
Right away I assumed not, but now I am not sure.


Actually, I think what is confusing me is that before, when talking  
about Additional and Alternate file access control mechanisms, you  
said that: " All others with ACE4_WRITE_ACL, ACE4_WRITE_OWNER,  
ACE4_DELETE_CHILD, and ACE4_DELETE are alternate."

I just wonder how that statement  relates to the statement that  
"Alternate permissions in the ACL can be enabled by either setting an  
ACL without providing full mask entries, or by setting the  
appropriate bit(s) in the corresponding mask entry or entries."


>
>> When comparing POSIX ACLs and the NFSv4 ACL + mask attributes as  
>> proposed
>> here, one obvious difference is that POSIX ACLs have only one mask  
>> entry,
>> while I propose three mask entries here. The reason for this is  
>> that POSIX
>> ACLs can at most grant read, write, and execute permissions, and  
>> so with
>> POSIX ACLs, the File Owner Class permissions are always identical  
>> to the
>> permissions granted to the owner, and the File Other Class  
>> permissions are
>> always identical to the permissions granted to others. With NFSv4  
>> ACLs,
>> OWNER@ and EVERYONE@ entries may grant additional permissions that  
>> go beyond
>> what POSIX read, write, and execute can grant, and we need a  
>> mechanism so
>> that those alternate permissions can be turned off by chmod and  
>> during file
>> create without destroying the permissions.
>
> Given that EVERYONE@ is not equivalent to the POSIX "other" class,  
> it could be trimmed down to two.
>
>> I would appreciate if you could take this alternative proposal into
>> consideration when deciding how to proceed with NFSv4 Minor
>> Version 1 at next week's IETF 66 meeting.
>
> This proposal certainly has its merits.  I have doubts about the  
> feasibility of adding two or three new file attributes, and new as- 
> yet-unimplemented semantics, into the minorversion1 draft.  I have  
> doubts about how this would be implemented on a Windows-based server.
>
> The current design specified in draft-ietf-nfsv4- 
> minorversion1-03.txt has implementation experience -- it's released  
> in Solaris 10 update 3, a shipping product.  It meets strict POSIX  
> requirements for those implementations that choose to conform to  
> POSIX.  I believe it's fully implementable on a Windows-based server.
>
> I too hope that this can be discussed at IETF 66.
>
> - Sam
>
>>
>>
>> Thanks and best regards,
>> Andreas
>>
>>> REFERENCES
>>>
>>> [1] Sam Falkner et al.: NFS Version 4 ACLs, draft-ietf-nfsv4- 
>>> acls-00.txt
>>>
>>> [2] POSIX 1003.1e/2c draft 17 (withdrawn),
>>> http://wt.xpilot.org/publications/posix.1e
>>>
>>> [3] Marius Aamodt Eriksen et al.: Mapping Between NFSv4 and Posix  
>>> Draft
>>> ACLs, draft-ietf-nfsv4-acl-mapping-04.txt
>>>
>>> [4] Spencer Shepler (editor): NFSv4 Minor Version 1,
>>> draft-ietf-nfsv4-minorversion1-03.txt
>>
>> -- 
>> Andreas Gruenbacher <agruen@suse.de>
>> Novell / SUSE Labs
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4


[-- Attachment #1.2: Type: text/html, Size: 69763 bytes --]

[-- Attachment #2: Type: text/plain, Size: 299 bytes --]

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Sam Falkner]

On Jul 7, 2006, at 9:45 PM, Sam Falkner wrote:

> On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:
>>
>> Alternative Proposal
>> ====================
>>
>> Instead of adding DENY entries to the ACL for the purpose of  
>> masking, attach
>> three optional attributes to each file: owner_class_mask,  
>> group_class_mask,
>> and other_class_mask. When those attributes are present, they  
>> define which
>> permissions in an ACE are effective.
>>
>> Each ACE is is restricted by one of these mask attributes in each  
>> access
>> check:
>>
>>  - OWNER@ entries and entries for the user@domain that currently  
>> owns the file
>>    are restricted by owner_class_mask.
>>
>>  - EVERYONE@ entries are restricted by other_class_mask.
>>
>>  - All other entries are restricted by group_class_mask.
>>
>> The effective permissions are computed as the bitwise and (&) of  
>> the ACE mask
>> and the associated class_mask attribute.
>
> I take it you mean that "the effective access mask bits for ACEs of  
> type ALLOW"?
>
>> When doing a chmod(2) or when applying a create mask, the  
>> owner_class_mask,
>> group_class_mask, and other_class_mask attributes are modified  
>> according to
>> the owner class, group class, and other class permissions of the mode
>> parameter as follows:
>>
>>  - The POSIX read permission implies the ACE4_READ_DATA,  
>> ACE4_READ_ATTRIBUTES,
>> ACE4_READ_ACL, and ACE4_SYNCHRONIZE bitmask flags.
>>
>>  - The POSIX write permission implies the ACE4_WRITE_DATA,  
>> ACE4_APPEND_DATA,
>> ACE4_WRITE_ATTRIBUTES, ACE4_DELETE_CHILD, and ACE4_SYNCHRONIZE  
>> bitmask flags.
>
> I'm not sure I agree about ACE4_WRITE_ATTRIBUTES, but that's a  
> minor detail.
>
>>  - The POSIX execute permission implies the ACE4_EXECUTE mask.
>
>> This saves us from bloating ACLs with DENY entries, is more  
>> efficient when
>> doing a chmod, and also saves us from destroying permissions in  
>> user provided
>> DENY entries.
>
> Yes, but at the cost of adding new file attributes...  Don't get me  
> wrong, I do see merit in this proposal, but I don't know if it'll  
> be acceptable.
>
>> When an ACL is set, then set all mask attributes to the values  
>> provided in the
>> same SETATTR operation, and set the remaining mask attributes to  
>> the union of
>> all ALLOW ACL entries in the ACL that the class applies to.
>
> This doesn't take the ordering of the ACL into account; is this  
> your intention?  So
>
> GROUP@:read_data/write_data:DENY
> GROUP@:read_data/write_data:ALLOW
>
> would result in a group_class_mask of read_data|write_data, right?   
> (I'm not saying it's wrong, I'm just making sure I understand.)
>
>> Without any further changes, NFSv4 clients not aware of the three  
>> optional
>> attributes would not be aware of the restrictions imposed by those  
>> masks when
>> querying for the ACL. This would create an interoperability  
>> problem, and
>> possible security holes. To solve this problem, we can extend the  
>> GETATTR
>> operation as follows:
>>
>> When a client requests the ACL attribute, check if it also  
>> requests one or
>> more of the three optional owner_class_mask, group_class_mask, or
>> other_class_mask attributes. If it does, then send the requested  
>> attributes
>> as they are. If the client requests only the ACL without any of  
>> the masks,
>> return an ACL with only effective mask flags set, and with all  
>> other flags
>> removed.
>
> I assume you mean in the ALLOW ACEs only, right?

More thoughts on this model and getattr.  Giving different versions  
of the ACL depending on how it's requested leads to problems.  To  
recap, if NFSv4.0 client asks for the post-chmod ACL, it'll get the  
inhibited version of the ACL.  Tools for modifying an ACL invariably  
do read/modify/write.  So NFSv4.0 client reads the stripped down ACL,  
modifies it, and writes it back.  At this point, information is lost  
-- the stripped down ACL is now the only ACL we have.  This leads to  
future environments where some classes of clients inadvertently do  
bad things, while others behave more correctly.

The ACL model in draft-ietf-nfsv4-minorversion1-03.txt always shows  
every client the entire, correct ACL, every time.

- Sam

>
>> Alternate permissions in the ACL can be enabled by either setting  
>> an ACL
>> without providing full mask entries, or by setting the appropriate  
>> bit(s) in
>> the corresponding mask entry or entries.
>
> Yes, I think I understand.
>
>> When comparing POSIX ACLs and the NFSv4 ACL + mask attributes as  
>> proposed
>> here, one obvious difference is that POSIX ACLs have only one mask  
>> entry,
>> while I propose three mask entries here. The reason for this is  
>> that POSIX
>> ACLs can at most grant read, write, and execute permissions, and  
>> so with
>> POSIX ACLs, the File Owner Class permissions are always identical  
>> to the
>> permissions granted to the owner, and the File Other Class  
>> permissions are
>> always identical to the permissions granted to others. With NFSv4  
>> ACLs,
>> OWNER@ and EVERYONE@ entries may grant additional permissions that  
>> go beyond
>> what POSIX read, write, and execute can grant, and we need a  
>> mechanism so
>> that those alternate permissions can be turned off by chmod and  
>> during file
>> create without destroying the permissions.
>
> Given that EVERYONE@ is not equivalent to the POSIX "other" class,  
> it could be trimmed down to two.
>
>> I would appreciate if you could take this alternative proposal into
>> consideration when deciding how to proceed with NFSv4 Minor
>> Version 1 at next week's IETF 66 meeting.
>
> This proposal certainly has its merits.  I have doubts about the  
> feasibility of adding two or three new file attributes, and new as- 
> yet-unimplemented semantics, into the minorversion1 draft.  I have  
> doubts about how this would be implemented on a Windows-based server.
>
> The current design specified in draft-ietf-nfsv4- 
> minorversion1-03.txt has implementation experience -- it's released  
> in Solaris 10 update 3, a shipping product.  It meets strict POSIX  
> requirements for those implementations that choose to conform to  
> POSIX.  I believe it's fully implementable on a Windows-based server.
>
> I too hope that this can be discussed at IETF 66.
>
> - Sam
>
>>
>>
>> Thanks and best regards,
>> Andreas
>>
>>> REFERENCES
>>>
>>> [1] Sam Falkner et al.: NFS Version 4 ACLs, draft-ietf-nfsv4- 
>>> acls-00.txt
>>>
>>> [2] POSIX 1003.1e/2c draft 17 (withdrawn),
>>> http://wt.xpilot.org/publications/posix.1e
>>>
>>> [3] Marius Aamodt Eriksen et al.: Mapping Between NFSv4 and Posix  
>>> Draft
>>> ACLs, draft-ietf-nfsv4-acl-mapping-04.txt
>>>
>>> [4] Spencer Shepler (editor): NFSv4 Minor Version 1,
>>> draft-ietf-nfsv4-minorversion1-03.txt
>>
>> -- 
>> Andreas Gruenbacher <agruen@suse.de>
>> Novell / SUSE Labs
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4


_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

T24gU2F0dXJkYXksIDguIEp1bHkgMjAwNiAwNTo0NSwgU2FtIEZhbGtuZXIgd3JvdGU6Cj4gT24g
SnVsIDcsIDIwMDYsIGF0IDU6NTUgQU0sIEFuZHJlYXMgR3J1ZW5iYWNoZXIgd3JvdGU6Cj4gPiBP
biBNb25kYXksIDMuIEp1bHkgMjAwNiAyMzoxMCwgQW5kcmVhcyBHcnVlbmJhY2hlciB3cm90ZToK
PiA+PiBIZWxsbywKPiA+Pgo+ID4+IEkgaGF2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHRoZSBwcm9i
bGVtcyBvZiBpbnRlcmFjdGlvbiBiZXR3ZWVuCj4gPj4gTkZTdjQgQUNMcyBhbmQgUE9TSVgsIGFu
ZCBwYXJ0aWN1bGFybHkgYWJvdXQgdGhlIGlzc3VlIG9mIG1hc2tpbmcKPiA+PiBwZXJtaXNzaW9u
cyB0aHJvdWdoIGNobW9kIGFuZCBhZnRlciBjcmVhdGluZyBmaWxlcyBvciBkaXJlY3Rvcmllcy4K
PiA+Cj4gPiBIZXJlIGlzIGEgZm9sbG93LXVwIGFmdGVyIHNvbWUgcGVyc29uYWwgZmVlZGJhY2sg
ZnJvbSBTYW0uIEkKPiA+IGJlbGlldmUgdGhhdCBkcmFmdC1pZXRmLW5mc3Y0LWFjbHMtMDAgaXMg
bm90IHJlYWR5IHRvIGJlY29tZSBwYXJ0IG9mIHRoZQo+ID4gTkZTdjQgTWlub3IgVmVyc2lvbiAx
IFJGQzogc29tZSBhc3N1bXB0aW9ucyBhcmUgbm90IGNvcnJlY3QgZnJvbSBhIFBPU0lYCj4gPiBw
b2ludCBvZiB2aWV3LCBhbmQgdGhlIHdheSBob3cgY2htb2QgYW5kIGZpbGUgY3JlYXRlIG1vZGVz
IGFyZSBhcHBsaWVkIHRvCj4gPiBORlN2NCBBQ0xzIGlzIHdlYWsgYW5kIG5vdCBndWFyYW50ZWVk
IHRvIGJlIGNvcnJlY3QuCj4KPiBJIGRpc2FncmVlIC0tIHNlZSBiZWxvdy4KCkhlcmUgYXJlIHNv
bWUgZmFjdHMgdG8gYmFjayBteSBwb2ludHM6IExldCdzIGFzc3VtZSB0aGF0IGEgZmlsZSBpbmhl
cml0cyB0aGUgCmZvbGxvd2luZyBBQ0wgd2hlbiBiZWluZyBjcmVhdGVkIChJIGFtIHVzaW5nIF4o
Li4uKSBoZXJlIHdpdGggdGhlIG1lYW5pbmcgb2YgCiJhbGwgYml0ZmxhZ3MgZXhjZXB0IC4uLiIp
OgoKCU9XTkVSQDpSRUFEX0RBVEEvV1JJVEVfREFUQTo6QUxMT1cKCU9XTkVSQDpeKFJFQURfREFU
QS9XUklURV9EQVRBKTo6REVOWQoJR1JPVVBAOlJFQURfREFUQTo6QUxMT1cKCXVzZXJAZG9tYWlu
OlJFQURfREFUQS9XUklURV9EQVRBOjpBTExPVwoJR1JPVVBAOl5SRUFEX0RBVEE6OkRFTlkKCXVz
ZXJAZG9tYWluOl4oUkVBRF9EQVRBL1dSSVRFX0RBVEEpOjpERU5ZCglFVkVSWU9ORUA6UkVBRF9E
QVRBOjpBTExPVwoKVGhpcyBhY2wgaXMgIndlbGwgc3RydWN0dXJlZCIgaW4gdGhlIFBPU0lYIHNl
bnNlOiBPV05FUkAgd2lsbCBvbmx5IGdldCB0aGUgCm93bmVyIHBlcm1pc3Npb25zIGFuZCBub25l
IG9mIHRoZSBvdGhlciBwZXJtaXNzaW9ucywgdXNlckBkb21haW4gYW5kIEdST1VQQCAKd2lsbCBv
bmx5IGdldCB0aGUgcGVybWlzc2lvbnMgaW50ZW5kZWQgZm9yIHRoZW0sIGFuZCBvbmx5IG90aGVy
cyAobmVpdGhlciAKT1dORVJAIG5vciB1c2VyQGRvbWFpbiBub3IgR1JPVVBAKSB3aWxsIGdldCBF
VkVSWU9ORUAgcGVybWlzc2lvbnM7IGluIG90aGVyIAp3b3JkcywgdGhlIGFjbCBpcyBldmVuIGNv
cnJlY3QgZm9yIG5vbi1tb25vdG9uaWMgcGVybWlzc2lvbnMuCgpBY2NvcmRpbmcgdG8gc2VjdGlv
biA1LjEgb2YgZHJhZnQtaWV0Zi1uZnN2NC1hY2xzIFsxXSwgdGhlIHJlc3VsdGluZyBmaWxlIG1v
ZGUgCnBlcm1pc3Npb24gYml0cyBmb3IgdGhpcyBhY2wgc2hhbGwgYmUgcnctci0tci0tLiBBZnRl
ciBhIGNobW9kIG9yIGEgZmlsZSAKY3JlYXRlLCBhbHRlcm5hdGUgZmlsZSBhY2Nlc3MgY29udHJv
bCBtZWNoYW5pc21zIG11c3QgYmUgZGlzYWJsZWQgYW5kIG9ubHkgCmFkZGl0aW9uYWwgZmlsZSBh
Y2Nlc3MgY29udHJvbCBtZWNoYW5pc21zIG1heSByZW1haW4gYWN0aXZlLiBBY2NvcmRpbmcgdG8g
ClBPU0lYLCBhZGRpdGlvbmFsIGZpbGUgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtcyByZXF1aXJl
IHRoYXQgbm8gdXNlciBtYXkgYmUgCmdyYW50ZWQgbW9yZSBwZXJtaXNzaW9ucyB0aGFuIHRoZSBy
ZXNwZWN0aXZlIGZpbGUgY2xhc3NlcyBwZXJtaXQuIEluIHRoaXMgCmNhc2UsIHVzZXJAZG9tYWlu
IGNsZWFybHkgaXMgbm90IGluIHRoZSBGaWxlIE93bmVyIENsYXNzLiAoQWNjb3JkaW5nIHRvIApQ
T1NJWCwgdXNlckBkb21haW4gbXVzdCBiZSBpbiB0aGUgRmlsZSBHcm91cCBDbGFzcy4pIFRoZSB1
c2VyQGRvbWFpbiB1c2VyIGlzIApncmFudGVkIFdSSVRFX0RBVEEgdGhvdWdoLCB3aGljaCBpcyAq
aW5jb3JyZWN0KiBmcm9tIGEgUE9TSVggcG9pbnQgb2Ygdmlldy4KCk5leHQsIGxldCdzIGFzc3Vt
ZSB0aGFuIGFuIEFDTCBjb250YWlucyB0aGUgZm9sbG93aW5nIHBhaXIgb2YgdXNlci1wcm92aWRl
ZCAKZW50cmllczoKCglHUk9VUEA6V1JJVEVfREFUQTo6REVOWQoJR1JPVVBAOlJFQURfREFUQTo6
QUxMT1cKCkNsZWFybHkgdGhlIHVzZXIncyBpbnRlbnRpb24gaXMgdG8gZGVueSBXUklURV9EQVRB
IGFjY2VzcyB0byBHUk9VUEAuIFRoZSAKYWxnb3JpdGhtIHRvIGFwcGx5IGEgbW9kZSB0byBhbiBl
eGlzdGluZyBBQ0wgd2lsbCByZW1vdmUgdGhlIFdSSVRFX0RBVEEgYml0IApmcm9tIHRoZSBHUk9V
UEA6V1JJVEVfREFUQTo6REVOWSBlbnRyeSB3aGVuIGEgY2htb2QoLi4uLCAwNzcwKSBpcyBkb25l
IAp0aG91Z2guIFRoaXMgaXMgY291bnRlciB0byB0aGUgdXNlcidzIGludGVudGlvbiwgc28gSSB3
b3VsZCBjYWxsIHRoYXQgKndyb25nKiAKYXMgd2VsbC4gSXQgYWxzbyB2aW9sYXRlcyB0aGUgcHJp
bmNpcGxlIG9mIGxlYXN0IHN1cnByaXNlLiBUaGVyZSByZWFsbHkgaXMgbm8gCnNhZmUgd2F5IHRv
IHRlbGwgdXNlci1wcm92aWRlZCBBQ0wgZW50cmllcyBmcm9tIGFydGlmaWNpYWxseSBtYWRlIHVw
IEFDTCAKZW50cmllcy4KCmRyYWZ0LWlldGYtbmZzdjQtYWNscyBpcyBtaXNzaW5nIGEgY2xlYXIg
Y2xhc3NpZmljYXRpb24gb2YgQUNMIGVudHJpZXMgaW50byAKdGhlIEZpbGUgT3duZXIsIEZpbGUg
R3JvdXAsIGFuZCBGaWxlIE90aGVyIGNsYXNzZXMuIEV2ZXJ5IEFDTCBlbnRyeSBtdXN0IGJlIApp
biBvbmUgb2YgdGhlIHRocmVlIGNsYXNzZXMgaW4gb3JkZXIgdG8gY29tcHV0ZSBhcHByb3ByaWF0
ZSBmaWxlIG1vZGUgCnBlcm1pc3Npb24gYml0cyB3aGVuIHNldHRpbmcgYW4gQUNMLCBhbmQgYWZ0
ZXIgaW5oZXJpdGluZyBwZXJtaXNzaW9ucy4gVGhpcyAKY2xhc3NpZmljYXRpb24gYWxzbyBkZXRl
cm1pbmVzIHdoaWNoIGVmZmVjdCBjaG1vZCB3aWxsIGhhdmUgb24gYW4gQUNMLgoKU28gZHJhZnQt
aWV0Zi1uZnN2NC1hY2xzIGlzICppbmNvcnJlY3QqIGFuZCAqd3JvbmcqIGZyb20gYSBQT1NJWCBw
b2ludCBvZiAKdmlldywgd2hpbGUgbXkgYWx0ZXJuYXRpdmUgcHJvcG9zYWwgaXMgY29ycmVjdCwg
YXBhcnQgZnJvbSBiZWluZyBzaW1wbGVyIHRvIAppbXBsZW1lbnQuIEkgaG9wZSB0aGF0IG15IGVt
YWlscyBhbmQgc29tZSBiYWNrZ3JvdW5kIHJlYWRpbmcgKGxpa2UgdGhlIGZpbGUgCmFjY2VzcyBy
ZWxhdGVkIHBhcnRzIG9mIHRoZSBQT1NJWCBkZWZpbml0aW9ucyB2b2x1bWUgWzVdLCBhIHBhcGVy
IHRoYXQgCmV4cGxhaW5zIFBPU0lYIEFDTHMgYW5kIGhvdyB0aGV5IGFyZSBpbXBsZW1lbnRlZCBv
biBMaW51eCBbNl0sIGFuZCBwZXJoYXBzIAoxMDAzLjFlIGRyYWZ0IDE3KSB3aWxsIGNvbnZpbmNl
IHlvdSBhYm91dCB0aGF0LgoKTm90ZSB0aGF0IGluIHRyYWRpdGlvbmFsIFBPU0lYLCBwZXJtaXNz
aW9ucyBmcm9tIG11bHRpcGxlIGZpbGUgY2xhc3NlcyB3aWxsIApuZXZlciBhY2N1bXVsYXRlOiBl
YWNoIHVzZXIgYWx3YXlzIGlzIGVpdGhlciBncmFudGVkIHRoZSBGaWxlIE93bmVyIApwZXJtaXNz
aW9uIGJpdHMsIHRoZSBGaWxlIEdyb3VwIHBlcm1pc3Npb24gYml0cywgb3IgdGhlIEZpbGUgT3Ro
ZXIgcGVybWlzc2lvbiAKYml0cy4gKEFkZGl0aW9uYWwgZmlsZSBhY2Nlc3MgY29udHJvbCBtZWNo
YW5pc21zIG1heSBmdXJ0aGVyIGxpbWl0IHRoZSAKcGVybWlzc2lvbnMgZ3JhbnRlZCwgYW5kIGFs
dGVybmF0aXZlIGZpbGUgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtcyBtYXkgCmZ1cnRoZXIgbGlt
aXQgb3IgZXh0ZW5kIHRoZSBwZXJtaXNzaW9ucyBncmFudGVkLikgUGVybWlzc2lvbnMgZnJvbSBt
dWx0aXBsZSAKYWNsIGVudHJpZXMgYWNjdW11bGF0ZSBpbiB0aGUgTkZTdjQgQUNMIG1vZGVsIHRo
b3VnaCwgYW5kIHNvIHVubGVzcyBhbiBhY2wgaXMgCiJ3ZWxsIHN0cnVjdHVyZWQiIGluIHRoZSBh
Ym92ZSBzZW5zZSwgcGVybWlzc2lvbnMgZnJvbSBtdWx0aXBsZSBjbGFzc2VzIG1heSAKYWNjdW11
bGF0ZS4KCj4gPiBJIHdpbGwgZmlyc3QgdHJ5IHRvIGNsYXJpZnkgc29tZSBvZiB0aGUgcG9pbnRz
IEkgdHJpZWQgdG8gbWFrZSBpbgo+ID4gdGhlIHByZXZpb3VzIHBvc3RpbmcgYW5kIHBvaW50IG91
dCBkZWZpY2llbmNpZXMgaW4KPiA+IGRyYWZ0LWlldGYtbmZzdjQtYWNscy0wMC4gVGhlbiBJIHdp
bGwgcHJvcG9zZSBhbiBhbHRlcm5hdGl2ZSBkZXNpZ24gd2hpY2gKPiA+IGlzIG1vcmUgY29ycmVj
dCB0aGFuIGludHJvZHVjaW5nIERFTlkgZW50cmllcyB0byBtYXNrIHBlcm1pc3Npb25zLiAoQXMg
YQo+ID4gYm9udXMsIGl0IGlzIGVhc2llciB0byBpbXBsZW1lbnQuIHRvby4pCj4gPgo+ID4+IE9u
IGEgVU5JWCBzeXN0ZW0gdGhhdCBzdXBwb3J0cyBORlN2NCBBQ0xzIG5hdGl2ZWx5LCBJIHRoaW5r
IHdlCj4gPj4gc2hvdWxkIHRyeSB0byBhY2NlcHQgYXMgd2lkZSBhIHJhbmdlIG9mIE5GU3Y0IEFD
THMgYXMgcG9zc2libGUsIGJ1dCB3ZQo+ID4+IG11c3QgbWFrZSBzdXJlIHRoYXQgd2UgY2FuIHBy
ZXNlcnZlIFBPU0lYIHNlbWFudGljcy4gSW4gcGFydGljdWxhciwgdGhpcwo+ID4+IG1lYW5zIHRo
YXQgQUNMcyBtYXkgY29udGFpbiBBQ0VzIGZvciB1c2VycyBvdGhlciB0aGFuIE9XTkVSQCwgR1JP
VVBALCBhbmQKPiA+PiBFVkVSWU9ORUAsIGFuZCB0aGF0IGNobW9kKDIpIG11c3QgY29udGludWUg
dG8gcHJvdmlkZSB0aGUgc2FtZSBraW5kcyBvZgo+ID4+IGd1YXJhbnRlZXMgYXMgd2l0aG91dCBO
RlN2NCBBQ0xzLgo+ID4+Cj4gPj4gSSBhbSBhc3N1bWluZyBoZXJlIHRoYXQgTkZTdjQgQUNMcyBz
aGFsbCBiZSBhbiBhZGRpdGlvbmFsIHJhdGhlciB0aGFuIGFuCj4gPj4gYWx0ZXJuYXRlIGZpbGUg
YWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtIGluIHRoZSBQT1NJWCBzZW5zZTogQWx0ZXJuYXRlCj4g
Pj4gZmlsZSBhY2Nlc3MgY29udHJvbCBtZWNoYW5pc21zIG11c3QgYGBiZSBlbmFibGVkIG9ubHkg
YnkgZXhwbGljaXQgdXNlcgo+ID4+IGFjdGlvbiwgb24gYSBwZXItZmlsZSBiYXNpcyBieSB0aGUg
ZmlsZSBvd25lciBvciBhIHVzZXIgd2l0aCB0aGUKPiA+PiBhcHByb3ByaWF0ZSBwcml2aWxlZ2Un
JywgYW5kIG11c3QgYGBiZSBkaXNhYmxlZCBmb3IgYSBmaWxlIGFmdGVyIHRoZSBmaWxlCj4gPj4g
cGVybWlzc2lvbiBiaXRzIGFyZSBjaGFuZ2VkIGZvciB0aGF0IGZpbGUgd2l0aCBjaG1vZCggKScn
IGFjY29yZGluZyB0bwo+ID4+IFBPU0lYLiBJbiBvdGhlciB3b3JkcywgbmV3bHkgY3JlYXRlZCBm
aWxlcyBvciBkaXJlY3RvcmllcyB3b3VsZCBoYXZlCj4gPj4gYWx0ZXJuYXRlIGZpbGUgYWNjZXNz
IGNvbnRyb2wgbWVjaGFuaXNtcyBkaXNhYmxlZC4gVGhpcyB3b3VsZCByZW5kZXIKPiA+PiBORlN2
NCBBQ0xzIGVzc2VudGlhbGx5IHVzZWxlc3MgZm9yIFVOSVggcHJvY2Vzc2VzLCBiZWNhdXNlIHRo
ZXkgd291bGQKPiA+PiBhbG1vc3QgYWx3YXlzIGJlIGRpc2FibGVkLCBhbmQgd291bGQgb25seSB3
b3JrIGZvciByZW1vdGUgcHJvY2Vzc2VzIHVudGlsCj4gPj4gYSBQT1NJWCBwcm9jZXNzIGNobW9k
cyBhIGZpbGUgb3IgY3JlYXRlcyBhIGRpcmVjdG9yeSwgd2hpY2ggd291bGRuJ3QgZ2V0Cj4gPj4g
dXMgdmVyeSBmYXIuIAo+ID4KPiA+IEFzIFNhbSBwb2ludGVkIG91dCwgYSBzdWJzZXQgb2YgTkZT
djQgQUNMcyBtYXBzIHRvIGFuIGFkZGl0aW9uYWwgZmlsZQo+ID4gYWNjZXNzIGNvbnRyb2wgbWVj
aGFuaXNtLCB3aGlsZSB0aGUgcmVzdCBnb2VzIGJleW9uZCB0aGF0LCBhbmQgdGhlcmVmb3JlCj4g
PiBpcyBhbiBhbHRlcm5hdGUgZmlsZSBhY2Nlc3MgY29udHJvbCBtZWNoYW5pc20uCj4KPiBZZXMg
LS0gQUxMT1cgQUNFcyBhcmUgYWx0ZXJuYXRlIGZpbGUgYWNjZXNzIGNvbnRyb2wsIGFuZCBERU5Z
IEFDRXMKPiBhcmUgYWRkaXRpb25hbCBmaWxlIGFjY2VzcyBjb250cm9sLgoKVGhpcyBjbGFzc2lm
aWNhdGlvbiBtYWtlcyBubyBzZW5zZSwgYW5kIGl0IGFsc28gZG9lcyBub3QgbWF0Y2ggd2hhdCB5
b3UgCnByb3Bvc2UgaW4gc2VjdGlvbiA1LjMgb2YgZHJhZnQtaWV0Zi1uZnN2NC1hY2xzLCBlaXRo
ZXI6IHRoZXJlIGFyZSBhY2xzIHRoYXQgCmNvbnRhaW4gQUxMT1cgZW50cmllcyB3aGljaCBhcmUg
c3RpbGwgb25seSBhbiBhZGRpdGlvbmFsIGZpbGUgYWNjZXNzIGNvbnRyb2wgCm1lY2hhbmlzbSwg
c28gd2UgcmVhbGx5IG5lZWQgdG8gY2xhc3NpZnkgdGhlbSBhcyBhbiBhZGRpdGlvbmFsIGZpbGUg
YWNjZXNzIApjb250cm9sIG1lY2hhbmlzbSBpbiBvcmRlciB0byBhdm9pZCBoYXZpbmcgdG8gZGlz
YWJsZSB0aGVtIGR1cmluZyBjaG1vZCBvciAKd2hlbiBpbmhlcml0aW5nIHBlcm1pc3Npb25zLiBJ
ZiBBTExPVyBBQ0VzIHdlcmUgYWx0ZXJuYXRlIGluIGdlbmVyYWwsIHRoZW4gd2UgCndvdWxkIGhh
dmUgdG8gZGlzYWJsZSB0aGVtIGFsbCBhZnRlciBhIGNobW9kLCBhbmQgSSB0aGluayB3ZSBhZ3Jl
ZSB0aGF0IHRoaXMgCndvdWxkIG1ha2UgQUNMcyBwcmFjdGljYWxseSB1c2VsZXNzIGluIGNvbWJp
bmF0aW9uIHdpdGggUE9TSVguCgpUaGUgb25seSBjbGFzc2lmaWNhdGlvbiB0aGF0IG1ha2VzIHNl
bnNlIGlzIGJ5IHRoZSBwZXJtaXNzaW9ucyB0aGF0IGFuIEFDTCAKZ3JhbnRzLiBZb3UgaGF2ZSBn
aXZlbiBhbiBleGFtcGxlIG9mIGFuIEFDTCB0aGF0IGNsZWFybHkgaXMgYW4gYWRkaXRpb25hbCAK
ZmlsZSBhY2Nlc3MgY29udHJvbCBtZWNoYW5pc20gb25seS4gV2l0aCB0aGlzIGtpbmQgb2YgY2xh
c3NpZmljYXRpb24sIGEgCnNpZ25pZmljYW50IHN1YnNldCBvZiBORlN2NCBBQ0xzIGNhbiBiZSB0
cmVhdGVkIGFzIGFuIGFkZGl0aW9uYWwgZmlsZSBhY2Nlc3MgCmNvbnRyb2wgbWVjaGFuaXNtLCB3
aGljaCBtYWtlcyB0aGVtIGFjdHVhbGx5IHVzZWZ1bCBldmVuIHdoZW4gUE9TSVggc3lzdGVtcyAK
YW5kIFdpbmRvd3MgKG9yIG90aGVyIHN5c3RlbXMgd2l0aCBORlN2NCBBQ0xzIG9yIHNpbWlsYXIp
IGludGVyYWN0IGFuZCBib3RoIApjaGFuZ2UgQUNMcy4KCj4gPiBJdCBpcyBpbXBvcnRhbnQgdG8g
dW5kZXJzdGFuZCBob3cgUE9TSVggZGVmaW5lcyBhZGRpdGlvbmFsIGZpbGUKPiA+IGFjY2VzcyBj
b250cm9sIG1lY2hhbmlzbXM6Cj4gPgo+ID4gW10gMy40IEFkZGl0aW9uYWwgRmlsZSBBY2Nlc3Mg
Q29udHJvbCBNZWNoYW5pc20KPiA+IFtdIEFuIGltcGxlbWVudGF0aW9uLWRlZmluZWQgbWVjaGFu
aXNtIHRoYXQgaXMgbGF5ZXJlZCB1cG9uIHRoZQo+ID4gW10gYWNjZXNzIGNvbnRyb2wgbWVjaGFu
aXNtcyBkZWZpbmVkIGhlcmUsIGJ1dCB3aGljaCBkbyBub3QgZ3JhbnQKPiA+IFtdIHBlcm1pc3Np
b25zIGJleW9uZCB0aG9zZSBkZWZpbmVkIGhlcmVpbiwgYWx0aG91Z2ggdGhleSBtYXkgZnVydGhl
cgo+ID4gW10gcmVzdHJpY3QgdGhlbS4gCj4gPgo+ID4gSW4gb3RoZXIgd29yZHMsIHdoZW4gYSBm
aWxlIGhhcyBqdXN0IGJlZW4gY3JlYXRlZCBhbmQgYWZ0ZXIgY2htb2QsCj4gPiB0aGUgZmlsZSBt
b2RlIHBlcm1pc3Npb24gYml0cyBkZWZpbmUgYW4gdXBwZXIgYm91bmQgdG8gdGhlIHBlcm1pc3Np
b25zCj4gPiBncmFudGVkIHRvIGFueW9uZSBvbiB0aGUgc3lzdGVtLCBhbmQgbm9ib2R5IGhhcyBh
ZGRpdGlvbmFsIHBlcm1pc3Npb25zLgo+ID4gQWRkaXRpb25hbCBwZXJtaXNzaW9ucyAoYXMgYW4g
YWx0ZXJuYXRlIGZpbGUgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtKSBtYXkKPiA+IGJlIGVuYWJs
ZWQgZXhwbGljaXRseSwgYnV0IHRoZSBuZXh0IGNobW9kIG11c3QgZGlzYWJsZSB0aGVtIGFnYWlu
Lgo+Cj4gVGhlIHVzZSBvZiB0aGUgd29yZCAiQWRkaXRpb25hbCIgaXMgY29uZnVzaW5nIGluIHRo
ZSBhYm92ZQo+IHNlbnRlbmNlLiAgOi0pICBJIHRoaW5rIHlvdSBtZWFuICJtb3JlIiwgb3Igc2lt
aWxhciwgYnV0ICJBZGRpdGlvbmFsIgo+IGhhcyBhIHZlcnkgc3BlY2lmaWMgbWVhbmluZyB3aGlj
aCAoSSB0aGluaykgaXNuJ3Qgd2hhdCB5b3UgbWVhbi4KCkkgaW5kZWVkIG1lYW50IG1vcmUgcGVy
bWlzc2lvbnMgYXMgaW4gYWRkaXRpb25hbCBtYXNrIGJpdHMgZ3JhbnRlZCwgYXMgb3Bwb3NlZCAK
dG8gYW4gYWRkaXRpb25hbCBmaWxlIGFjY2VzcyBjb250cm9sIG1lY2hhbmlzbSBpbiB0aGUgc2Vu
c2UgaG93IFBPU0lYIGRlZmluZXMgCnRoaXMgdGVybS4KCj4gPiBXZSBjYW4gY2xhc3NpZnkgdGhl
IHBlcm1pc3Npb25zIHRoYXQgTkZTdjQgQUNMcyBncmFudCBpbnRvIGFkZGl0aW9uYWwgYW5kCj4g
PiBhbHRlcm5hdGUgbWVjaGFuaXNtcyBhcyBmb2xsb3dzOiBldmVyeXRoaW5nIGNvdmVyZWQgYnkg
dGhlIFBPU0lYCj4gPiByZWFkL3dyaXRlL2V4ZWN1dGUgcGVybWlzc2lvbnMgKHN1Y2ggYXMgQUNF
NF9SRUFEX0RBVEEsIGJ1dCBhbHNvCj4gPiBBQ0U0X0FQUEVORF9EQVRBKSBpcyBhZGRpdGlvbmFs
LCB3aGlsZSBldmVyeXRoaW5nIGJleW9uZCB0aGF0IChzdWNoIGFzCj4gPiBBQ0U0X1dSSVRFX09X
TkVSKSBpcyBhbHRlcm5hdGUuCj4KPiBOb3RlIHdlbGw6IHRoaXMgaXMgcXVpdGUgZGlmZmVyZW50
IGZyb20gZHJhZnQtaWV0Zi1uZnN2NC0KPiBtaW5vcnZlcnNpb24xLTAzLnR4dCwgaS5lLiB0aGlz
IGlzIGFuIGFsdGVybmF0ZSBwcm9wb3NhbC4KClllcywgdGhpcyBpcyBhIGRpZmZlcmVudCBhcHBy
b2FjaCBvZiBjbGFzc2lmeWluZyBORlN2NCBBQ0xzIGludG8gYWRkaXRpb25hbCAKYW5kIGFsdGVy
bmF0ZSBmaWxlIGFjY2VzcyBjb250cm9sIG1lY2hhbmlzbXMsIHdoaWNoIGNvbXBsaWVzIHRvIFBP
U0lYIGFzIHdlbGwgCmFzIHRvIHRoZSBjdXJyZW50IE5GU3Y0IFJGQy4gSXQgY29uZmxpY3RzIHdp
dGggZHJhZnQtaWV0Zi1uZnN2NC1hY2xzLCBhbmQgYnkgCmltcGxpY2F0aW9uIHdpdGggZHJhZnQt
aWV0Zi1uZnN2NC1taW5vcnZlcnNpb24xLTAzIFs0XSwgd2hpY2ggaW5jbHVkZXMgdGhlIApzYW1l
IHRleHQuCgpOb3RlIHRoYXQgZHJhZnQtaWV0Zi1uZnN2NC1hY2xzIGlzIGluY29uc2lzdGVudCBp
biBpdHNlbGY6IHRoZSBhbGdvcml0aG0gaW4gCnNlY3Rpb24gNS4zIHJlc3RyaWN0cyB3aGljaCBw
ZXJtaXNzaW9ucyBhbiBBQ0wgZ3JhbnRzIGJ5IG1hc2tpbmcgcGVybWlzc2lvbnMgCih3aGljaCBp
bXBsaWVzIHRoYXQgeW91IGFyZSBjbGFzc2lmeWluZyBieSBwZXJtaXNzaW9uIGFzIG9wcG9zZWQg
dG8gdHVybmluZyAKb2ZmIGFsbCBBTExPVyBlbnRyaWVzKSwgd2hpbGUgc2VjdGlvbiAxNC40IHNh
eXMgdGhhdCAidGhlIEFMTE9XIHR5cGUgb2YgQUNFIAppcyBjb25zaWRlcmVkIHRvIGJlIGFuIGFs
dGVybmF0ZSBmaWxlIGFjY2VzcyBjb250cm9sIG1lY2hhbmlzbSBiZWNhdXNlIGl0IGNhbiAKZnVy
dGhlciBleHRlbmQgdGhlIHBlcm1pc3Npb25zIG9mIGEgdXNlciIuCgo+ID4gVW5kZXIgdGhpcyBk
ZWZpbml0aW9uLCBhbGwgTkZTdjQgQUNMcyB0aGF0IGdyYW50IG5vIG1vcmUgdGhhbgo+ID4gQUNF
NF9SRUFEX0RBVEEsIEFDRTRfTElTVF9ESVJFQ1RPUlksIEFDRTRfV1JJVEVfREFUQSwgCj4gPiBB
Q0U0X0FERF9GSUxFLCBBQ0U0X0FQUEVORF9EQVRBLCBBQ0U0X0FERF9TVUJESVJFQ1RPUlksCj4g
PiBBQ0U0X1JFQURfTkFNRURfQVRUUlMsIEFDRTRfV1JJVEVfTkFNRURfQVRUUlMsIEFDRTRfRVhF
Q1VURSwKPiA+IEFDRTRfUkVBRF9BVFRSSUJVVEVTLCBBQ0U0X1dSSVRFX0FUVFJJQlVURVMsIEFD
RTRfUkVBRF9BQ0wsIGFuZAo+ID4gQUNFNF9TWU5DSFJPTklaRSB3b3VsZCBjb3VudCBhcyBhZGRp
dGlvbmFsIGFjY2VzcyBjb250cm9sCj4gPiBtZWNoYW5pc21zLiBBbGwgb3RoZXJzIHdpdGggQUNF
NF9XUklURV9BQ0wsIEFDRTRfV1JJVEVfT1dORVIsCj4gPiBBQ0U0X0RFTEVURV9DSElMRCwgYW5k
IEFDRTRfREVMRVRFIGFyZSBhbHRlcm5hdGUuCgpGdXJ0aGVyIGJlbG93IGluIHlvdXIgcmVwbHkg
eW91IHdyb3RlOgo+IEknbSBub3Qgc3VyZSBJIGFncmVlIGFib3V0IEFDRTRfV1JJVEVfQVRUUklC
VVRFUywgYnV0IHRoYXQncyBhIG1pbm9yCj4gZGV0YWlsLgoKSSBzdGFuZCBjb3JyZWN0ZWQgdGhh
dCBBQ0U0X1dSSVRFX0FUVFJJQlVURVMgaXMgYW4gYWx0ZXJuYXRlIHBlcm1pc3Npb24gcmF0aGVy
IAp0aGFuIGFuIGFkZGl0aW9uYWwgb25lOiB0aGUgUE9TSVggcmVhZC93cml0ZS9leGVjdXRlIHBl
cm1pc3Npb25zIGRvIG5vdCBhbGxvdyAKdG8gd3JpdGUgdG8gaW5vZGUgYXR0cmlidXRlcy4KCj4g
SSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgaXMgZ2FpbmVkIGJ5IHRoaXMgZGVzaWduYXRpb24gb2Yg
YWRkaXRpb25hbAo+IGFjY2VzcyBjb250cm9sIG1lY2hhbmlzbXMuCgpUaGUgYmVuZWZpdCBpcyB0
aGF0IGEgbW9yZSByZWFzb25hYmxlIHNldCBvZiBwZXJtaXNzaW9ucyBjYW4gcmVtYWluIGFjdGl2
ZSAKYWNyb3NzIGNobW9kIGFuZCBwZXJtaXNzaW9uIGluaGVyaXRhbmNlOiBpZiB3ZSBhc3N1bWUg
dGhhdCBBTExPVyBBQ0VzIGFyZSAKYWx0ZXJuYXRpdmUsIGFsbCBBTExPVyBBQ0VzIHdpbGwgaGF2
ZSB0byBiZSBkaXNhYmxlZCB3aGVuIGEgY2htb2QgaXMgZG9uZSwgb3IgCmluIHRoZSBwZXJtaXNz
aW9ucyB0aGF0IGEgZmlsZSBpbmhlcml0cy4gQSBjaG1vZCBmb3JtIG9uZSBtb2RlIHRvIGFub3Ro
ZXIgYW5kIApiYWNrIHdpbGwgZGlzYWJsZSBhbGwgYWx0ZXJuYXRpdmUgZmlsZSBhY2Nlc3MgY29u
dHJvbCBtZWNoYW5pc21zOyB0aGVyZSBpcyBubyAKd2F5IGFyb3VuZCB0aGF0LgoKSWYgd2UgYXNz
dW1lIHRoYXQgY2VydGFpbiBwZXJtaXNzaW9ucyBhcmUgaW4gdGhlIGFkZGl0aW9uYWwgY2xhc3Mg
YW5kIG90aGVycyAKYXJlIGluIHRoZSBhbHRlcm5hdGl2ZSBjbGFzcywgdGhlbiB3ZSBjYW4gZGlz
YWJsZSBvbmx5IHRob3NlIGFkZGl0aW9uYWwgCnBlcm1pc3Npb25zIHdoaWNoIGV4Y2VlZCB3aGF0
IHRoZSBhc3NvY2lhdGVkIGZpbGUgY2xhc3MgcGVybWl0cyAocmVtZW1iZXIgCnRoYXQgdGhlIGZp
bGUgY2xhc3NlcyBkZWZpbmUgdGhlIG1heGltdW0gcGVybWlzc2lvbnMgdGhhdCBhIG1lbWJlciBv
ZiB0aGF0IApjbGFzcyBtYXkgaGF2ZS4gV2Ugd2lsbCBhbHdheXMgZGlzYWJsZSBhbGwgYWx0ZXJu
YXRpdmUgcGVybWlzc2lvbnMgdXBvbiAKY2htb2QsIGJlY2F1c2UgdGhvc2UgYXJlIHRoZSBlbnRy
aWVzIHdoaWNoIGV4Y2VlZCB3aGF0IHRoZSBmaWxlIGNsYXNzIG1heSAKcGVybWl0IGJ5IGRlZmlu
aXRpb24sIGJ1dCB3ZSB3aWxsIGxlYXZlIGFzIG11Y2ggb2YgdGhlIGFkZGl0aW9uYWwgCnBlcm1p
c3Npb25zIGludGFjdCBhcyBwb3NzaWJsZS4KCkNvbnNpZGVyIHRoaXMgQUNMIChJIGhhdmUgdXNl
ZCB0aGUgc2FtZSBleGFtcGxlIGFib3ZlIGFscmVhZHkpOgoKCU9XTkVSQDpSRUFEX0RBVEEvV1JJ
VEVfREFUQTo6QUxMT1cKCU9XTkVSQDpeKFJFQURfREFUQS9XUklURV9EQVRBKTo6REVOWQoJR1JP
VVBAOlJFQURfREFUQTo6QUxMT1cKCXVzZXJAZG9tYWluOlJFQURfREFUQS9XUklURV9EQVRBOjpB
TExPVwoJR1JPVVBAOl5SRUFEX0RBVEE6OkRFTlkKCXVzZXJAZG9tYWluOl4oUkVBRF9EQVRBL1dS
SVRFX0RBVEEpOjpERU5ZCglFVkVSWU9ORUA6UkVBRF9EQVRBOjpBTExPVwoKV2l0aCB0aGUgQUxM
T1cgPSBhbHRlcm5hdGl2ZSBjbGFzc2lmaWNhdGlvbiwgYWxsIGFsbG93IGVudHJpZXMgd291bGQg
Z2V0IApkaXNhYmxlZCwgYW5kIHNvIHRoaXMgQUNMIHdvdWxkIG5vdCBncmFudCBhbnkgcGVybWlz
c2lvbnMgdG8gYW55Ym9keSBubyAKbWF0dGVyIHdoaWNoIGNobW9kIG1vZGUgaXMgdXNlZC4gV2l0
aCB0aGUgY2xhc3NpZmljYXRpb24gSSBhbSBwcm9wb3NpbmcsIHRoaXMgCmZpbGUgd291bGQgaGF2
ZSBydy1ydy1yLS0gZmlsZSBtb2RlIHBlcm1pc3Npb24gYml0cy4gQSBjaG1vZCB0byBydy1yLS0t
LS0gCndvdWxkIGRpc2FibGUgdGhlIHVzZXJAZG9tYWluOldSSVRFX0RBVEEgYW5kIEVWRVJZT05F
QDpSRUFEX0RBVEEgcGVybWlzc2lvbnMsIApidXQgdGhlIG90aGVyIHBlcm1pc3Npb25zIHdvdWxk
IHN0aWxsIHJlbWFpbiBlZmZlY3RpdmUuCgpOb3RlIHRoYXQgdGhpcyBpcyBhY3R1YWxseSB0aGUg
YmVoYXZpb3IgeW91IGFyZSBkZXNjcmliaW5nIGluIHNlY3Rpb24gNS4zIG9mIApkcmFmdC1pZXRm
LW5mc3Y0LWFjbHMtMDAsIHRoZSBkcmFmdCBpcyBvbmx5IG1pc3NpbmcgYSBjbGVhciBjbGFzc2lm
aWNhdGlvbiBvZiAKQUNFcyBpbnRvIHRoZSBGaWxlIE93bmVyLCBGaWxlIEdyb3VwLCBhbmQgRmls
ZSAgT3RoZXIgY2xhc3Nlcy4KCk9uZSBlc3NlbnRpYWwgZGlmZmVyZW5jZSBiZXR3ZWVuIGRyYWZ0
LWlldGYtbmZzdjQtYWNscy0wMCBhbmQgbXkgcHJvcG9zYWwgaXMgCnRoZSBtZWNoYW5pc20gdXNl
ZCB0byByZXN0cmljdCB0aGUgcGVybWlzc2lvbnMgdGhhdCBhbiBBQ0wgZ3JhbnRzOiAKZHJhZnQt
aWV0Zi1uZnN2NC1hY2xzLTAwIGluc2VydHMgREVOWSBlbnRyaWVzIGluIHRoZSBhY2wgYXQgdGhl
IGFwcHJvcHJpYXRlIApwbGFjZXMgYW5kIHVwZGF0ZXMgdGhlbSBsYXRlciBhcyBhcHByb3ByaWF0
ZSwgd2hpbGUgbXkgcHJvcG9zYWwgaW50cm9kdWNlcyAKb3B0aW9uYWwgbWFzayBhdHRyaWJ1dGVz
IGFuZCBvbmx5IHVwZGF0ZXMgdGhvc2UgYXR0cmlidXRlcy4KCldoaWxlIGRyYWZ0LWlldGYtbmZz
djQtYWNscy0wMCBzdHlsZSBBQ0xzIGNhbiBiZSBzZW50IHRvIGFsbCBORlN2NCBjbGllbnRzIAp1
bm1vZGlmaWVkLCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgd2hlbiBzZW5kaW5nIEFDTHMgdG8gY2xp
ZW50cyBpbiB0aGUgCnByZXNlbmNlIG9mIG1hc2sgYXR0cmlidXRlczogaWYgYSBjbGllbnQgaXMg
YXdhcmUgb2YgdGhlIG1hc2sgYXR0cmlidXRlcywgd2UgCmNhbiBzZW5kIHRoZSBBQ0wgZGlyZWN0
bHkuIElmIHRoZSBjbGllbnQgaXMgdW5hd2FyZSBvZiB0aGUgbWFzayBhdHRyaWJ1dGVzLCAKd2Ug
Y2FuIGNob29zZSB0byBlaXRoZXIgc2VuZCBhbiBBQ0wgdGhhdCBvbmx5IGNvbnRhaW5zIGFsbCB0
aGUgZWZmZWN0aXZlIApwZXJtaXNzaW9ucyBhbmQgd2l0aCB0aGUgbWFza2VkIHBlcm1pc3Npb25z
IHJlbW92ZWQsIG9yIHdlIGNvdWxkIGZpcnN0IGluc2VydCAKREVOWSBlbnRyaWVzIGluIHRoZSBB
Q0wgd2Ugc2VuZCBzaW1pbGFyIHRvIHNlY3Rpb24gNS4zIG9mIApkcmFmdC1pZXRmLW5mc3Y0LWFj
bHMtMDAgKGJ1dCB3aXRoIHRoZSBjbGFzc2lmaWNhdGlvbiBvZiBBQ0VzIGludG8gdGhlIGZpbGUg
CmNsYXNzZXMgY2xlYW5lZCB1cCkuCgo+IElmIHlvdSByZWFsbHkgc2F5IHRoYXQgdGhpcyBBQ0w6
IAo+Cj4gT1dORVJAOnJlYWRfZGF0YTphbGxvdwo+IGZyaWVuZEB5b3VyLmNvbTpyZWFkX2RhdGE6
YWxsb3cKPgo+IGlzIGFkZGl0aW9uYWwgZmlsZSBhY2Nlc3MgY29udHJvbCwKClllcy4KCj4gdGhl
biB3aGF0IGlzIHRoZSBtb2RlIG9uIHN1Y2ggYSBmaWxlPwoKVGhlIG1vZGUgaXMgci0tci0tLS0t
LCB3aGljaCBkb2VzICpub3QqIGltcGx5IHRoYXQgdGhlIG93bmluZyBncm91cCBoYXMgcmVhZCAK
YWNjZXNzLgoKPiBVbmxlc3MgdGhlIG1vZGUgc2F5cyAiZ3JvdXAgY2FuIHJlYWQiLCB0aGVuIGZy
aWVuZEB5b3VyLmNvbSAKPiB3b3VsZG4ndCBiZSBhYmxlIHRvIHJlYWQsIGlmIHRoZSBBQ0wgaXMg
YWRkaXRpb25hbCBmaWxlIGFjY2Vzcwo+IGNvbnRyb2wuCgpUaGF0J3MgY29ycmVjdC4KCj4gV2hh
dCBpZiB5b3Ugd2FudCBmcmllbmRAeW91ci5jb20gdG8gYmUgYWJsZSB0byByZWFkLCBidXQgeW91
IGRvbid0IHdhbnQgdGhlCj4gZmlsZSdzIG93bmluZyBncm91cCB0byByZWFkPyAKClBPU0lYIGRv
ZXMgbm90IHJlcXVpcmUgdGhhdCByLS1yLS0tLS0gZmlsZSBtb2RlIHBlcm1pc3Npb24gYml0cyBn
aXZlIHRoZSAKb3duaW5nIGdyb3VwIHdyaXRlIGFjY2Vzcy4gVGhlIG93bmluZyBncm91cCBwZXJt
aXNzaW9ucyBkZXBlbmQgb24gd2hpY2ggCmVudHJpZXMgYXJlIGluIHRoZSBhY2w6IHdpdGggRmls
ZSBHcm91cCBDbGFzcyBwZXJtaXNzaW9ucyBvZiByLS0sIGlmIHRoZSBhY2wgCmNvbnRhaW5zIGEg
R1JPVVBAOlJFQURfREFUQTo6QUxMT1cgZW50cnksIHRoZSBvd25pbmcgZ3JvdXAgaXMgZ3JhbnRl
ZCAKUkVBRF9EQVRBIGFjY2Vzcy4gV2l0aCBubyBHUk9VUEAgZW50cnksIGEgR1JPVVBAOldSSVRF
X0RBVEE6OkFMTE9XIGVudHJ5LCBvciAKYSBHUk9VUEA6UkVBRF9EQVRBOjpERU5ZIGVudHJ5IGJl
Zm9yZSBvdGhlciBlbnRyaWVzIHRoYXQgd291bGQgZ2l2ZSBHUk9VUEAgCnJlYWQgYWNjZXNzLCBH
Uk9VUEAgd291bGQgbm90IGJlIGdyYW50ZWQgUkVBRF9EQVRBIGFjY2Vzcy4KClRoZXJlIGlzIG9u
ZSBvdGhlciBjYXNlIHRvIGxvb2sgYXQgdGhvdWdoOiB3aGlsZSBhIGNobW9kIHdpbGwgZGlzYWJs
ZSBhbGwgCmFsdGVybmF0ZSBwZXJtaXNzaW9ucyBhbmQgbm8gYWx0ZXJuYXRlIHBlcm1pc3Npb25z
IHdpbGwgYmUgZWZmZWN0aXZlIGZvciAKbmV3bHkgY3JlYXRlZCBmaWxlcywgdGhlIG1hc2sgYXR0
cmlidXRlcyBjYW4gYmUgc2V0IGV4cGxpY2l0bHksIGFuZCBhbHRlcm5hdGUgCnBlcm1pc3Npb25z
IG1heSBiZSBlbmFibGVkLiBEZXBlbmRpbmcgb24gd2hpY2ggcGVybWlzc2lvbnMgdGhlIEFDTCBn
cmFudHMsIAp0aGlzIG1heSBjYXVzZSBhbHRlcm5hdGUgcGVybWlzc2lvbnMgdG8gYmVjb21lIGVm
ZmVjdGl2ZSAoYWx0ZXJuYXRlIGZpbGUgCmFjY2VzcyBjb250cm9sIG1lY2hhbmlzbSksIGFuZCBp
biB0aGlzIGNhc2UsIG1vcmUgcGVybWlzc2lvbnMgbWF5IGJlIGdyYW50ZWQgCnRoYW4gdGhlIGZp
bGUgbW9kZSBwZXJtaXNzaW9uIGJpdHMgaW1wbHkuCgpTZXR0aW5nIHRoZSBtYXNrIGF0dHJpYnV0
ZXMgc2hvdWxkIGNhdXNlIHRoZSBmaWxlIG1vZGUgcGVybWlzc2lvbiBiaXRzIHRvIGJlIApzZXQg
dG8gdGhlIHZhbHVlIHRoYXQgbW9zdCBjbG9zZWx5IG1hdGNoZXMgdGhlIG1hc2sgYXR0cmlidXRl
cy4gKEZvciBleGFtcGxlLCAKc2V0dGluZyB0aGUgUkVBRF9EQVRBIGJpdG1hc2sgaW4gZ3JvdXBf
Y2xhc3NfbWFzayBzaG91bGQgYWxzbyBzZXQgdGhlIHJlYWQgCkZpbGUgR3JvdXAgQ2xhc3MgcGVy
bWlzc2lvbikuCgpJIHByb3Bvc2VkIHRoYXQgd2hlbiBhIFNFVEFUVFIgb2YgQUNMIGlzIGRvbmUg
d2l0aG91dCBhbHNvIHNldHRpbmcgdGhlIHRocmVlIAoqX2NsYXNzX21hc2sgYXR0cmlidXRlcywg
dGhlbiB0aG9zZSpfY2xhc3NfbWFzayBhdHRyaWJ1dGVzIHRoYXQgYXJlIG5vdCAKc3BlY2lmaWVk
IHNob3VsZCBiZSBjb21wdXRlZCBhcyB0aGUgdW5pb24gb2YgdGhlIG1hc2sgYml0cyBvZiB0aGUg
ZW50cmllcyBpbiAKdGhlIHJlc3BlY3RpdmUgY2xhc3MuIFRoaXMgbWVhbnMgdGhhdCBhIFNFVEFU
VFIgb2YgQUNMIG1heSBvciBtYXkgbm90IGFtb3VudCAKdG8gYW4gYWx0ZXJuYXRlIGZpbGUgYWNj
ZXNzIGNvbnRyb2wgb3BlcmF0aW9uLgoKSSBoaWdobHkgcmVjb21tZW5kIHRvIHJlYWQgUE9TSVgg
QWNjZXNzIENvbnRyb2wgTGlzdHMgb24gTGludXggWzZdLgoKPiA+IEFzIHNhaWQgYWxyZWFkeSwg
dGhlIFBPU0lYIGZpbGUgbW9kZSBwZXJtaXNzaW9uIGJpdHMgZGVmaW5lIHRoZQo+ID4gcGVybWlz
c2lvbnMgb2YgdGhyZWUgY2xhc3Nlczogb3duZXIsIGdyb3VwLCBhbmQgb3RoZXIuIEFuIGFkZGl0
aW9uYWwKPiA+IGZpbGUgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtIG1heSBvbmx5IGZ1cnRoZXIg
cmVzdHJpY3QgdGhlIHBlcm1pc3Npb25zCj4gPiBncmFudGVkIHRvIHRob3NlIGNsYXNzZXMuCj4g
Pgo+ID4gVG8gbWFwIE5GU3Y0IEFDTHMgdG8gYW4gYWRkaXRpb25hbCBmaWxlIGFjY2VzcyBjb250
cm9sIG1lY2hhbmlzbSwKPiA+Cj4gPiAgLSB3ZSBtdXN0IG1hcCBlYWNoIE5GU3Y0IEFDTCBlbnRy
eSB0byBleGFjdGx5IG9uZSBvZiB0aGUgdGhyZWUKPiA+IGNsYXNzZXMuCj4gPgo+ID4gIC0gd2Ug
bXVzdCBlbnN1cmUgdGhhdCB0aGUgQUNMIGRvZXMgbm90IGdyYW50IGFueSBwZXJtaXNzaW9ucyB0
aGF0Cj4gPiBnbyBiZXlvbmQgdGhlIGNsYXNzIHBlcm1pc3Npb25zIGFmdGVyIGEgY2htb2Qgb3Ig
Y3JlYXRlLgo+Cj4gQWRkaXRpb25hbCBGaWxlIEFjY2VzcyBDb250cm9sIG11c3Qgbm90IGdyYW50
IGJleW9uZCB0aGUgY2xhc3MKPiBwZXJtaXNzaW9ucyAqZXZlciosIG5vdCBqdXN0IGFmdGVyIGNy
ZWF0ZSBvciBjaG1vZC4KPgo+ID4gIC0gaW4gcGFydGljdWxhciwgd2UgbXVzdCBlbnN1cmUgdGhh
dCB0aGUgQUNMIGdyYW50cyBubyAiYWx0ZXJuYXRlIgo+ID4gICAgcGVybWlzc2lvbnMgYWZ0ZXIg
YSBjaG1vZCBvciBjcmVhdGUuCj4KPiBJIGRvbid0IHVuZGVyc3RhbmQgdGhpczsgeW91IGJlZ2Fu
IHRoaXMgc2VjdGlvbiB3aXRoICJUbyBtYXAgTkZTdjQKPiBBQ0xzIHRvIGFuIGFkZGl0aW9uYWwu
Li4iLCBidXQgaGVyZSwgeW91IHNlZW0gdG8gYmUgZGVzY3JpYmluZyBBQ0xzCj4gYXMgYW4gYWx0
ZXJuYXRlIGZpbGUgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtLgoKSSBhbSBzYXlpbmcgdGhhdCBw
ZXJtaXNzaW9ucyBjbGFzc2lmaWVkIGFzIGFsdGVybmF0ZSBjYW4gbmV2ZXIgYmVjb21lIAplZmZl
Y3RpdmUgYXMgcGFydCBvZiBhbiBhZGRpdGlvbmFsIGZpbGUgYWNjZXNzIGNvbnRyb2wgbWVjaGFu
aXNtLiBUaGlzIG1lYW5zIAp0aGF0IHRoZSBBQ0wgbWF5IHN0aWxsIGNvbnRhaW4gc3VjaCBhbHRl
cm5hdGUgcGVybWlzc2lvbnMsIGJ1dCB3ZSBtdXN0IGVuc3VyZSAKdGhhdCB0aGVzZSBwZXJtaXNz
aW9ucyB3aWxsIG5vdCBiZWNvbWUgZWZmZWN0aXZlIGltcGxpY2l0bHkuCgo+ID4gV2UgYXJlIGZy
ZWUgdG8gcHJvdmlkZSBtZWNoYW5pc21zIGJ5IHdoaWNoIG1vcmUgcGVybWlzc2lvbnMgbWF5IGJl
Cj4gPiBlbmFibGVkIGJ5IGV4cGxpY2l0IHVzZXIgYWN0aW9uLCBvbiBhIHBlci1maWxlIGJhc2lz
IGJ5IHRoZSBmaWxlIG93bmVyIG9yCj4gPiBhIHVzZXIgd2l0aCB0aGUgYXBwcm9wcmlhdGUgcHJp
dmlsZWdlLCBhY2NvcmRpbmcgdG8gUE9TSVguCgouLi4gYW5kIHRoaXMgd291bGQgY291bnQgYXMg
YW4gYWx0ZXJuYXRlIGFjY2VzcyBjb250cm9sIG1lY2hhbmlzbSB0aGVuLgoKPiA+IFRoZSBQT1NJ
WCBkZWZpbml0aW9ucyBvZiB0aGUgdGhyZWUgZmlsZSBwZXJtaXNzaW9uIGNsYXNzZXMgYXJlOgo+
ID4KPiA+IFtdIDMuMTczIEZpbGUgT3duZXIgQ2xhc3MKPiA+IFtdIFRoZSBwcm9wZXJ0eSBvZiBh
IGZpbGUgaW5kaWNhdGluZyBhY2Nlc3MgcGVybWlzc2lvbnMgZm9yIGEKPiA+IFtdIHByb2Nlc3Mg
cmVsYXRlZCB0byB0aGUgdXNlciBpZGVudGlmaWNhdGlvbiBvZiBhIHByb2Nlc3MuIEEgcHJvY2Vz
cwo+ID4gW10gaXMgaW4gdGhlIGZpbGUgb3duZXIgY2xhc3Mgb2YgYSBmaWxlIGlmIHRoZSBlZmZl
Y3RpdmUgdXNlciBJRCBvZiB0aGUKPiA+IFtdIHByb2Nlc3MgbWF0Y2hlcyB0aGUgdXNlciBJRCBv
ZiB0aGUgZmlsZS4KPiA+Cj4gPiBbXSAzLjE2NiBGaWxlIEdyb3VwIENsYXNzCj4gPiBbXSBUaGUg
cHJvcGVydHkgb2YgYSBmaWxlIGluZGljYXRpbmcgYWNjZXNzIHBlcm1pc3Npb25zIGZvciBhIHBy
b2Nlc3MKPiA+IFtdIHJlbGF0ZWQgdG8gdGhlIGdyb3VwIGlkZW50aWZpY2F0aW9uIG9mIGEgcHJv
Y2Vzcy4gQSBwcm9jZXNzIGlzIGluCj4gPiBbXSB0aGUgZmlsZSBncm91cCBjbGFzcyBvZiBhIGZp
bGUgaWYgdGhlIHByb2Nlc3MgaXMgbm90IGluIHRoZSBmaWxlCj4gPiBbXSBvd25lciBjbGFzcyBh
bmQgaWYgdGhlIGVmZmVjdGl2ZSBncm91cCBJRCBvciBvbmUgb2YgdGhlIHN1cHBsZW1lbnRhcnkK
PiA+IFtdIGdyb3VwIElEcyBvZiB0aGUgcHJvY2VzcyBtYXRjaGVzIHRoZSBncm91cCBJRCBhc3Nv
Y2lhdGVkIHdpdGggdGhlCj4gPiBbXSBmaWxlLiBPdGhlciBtZW1iZXJzIG9mIHRoZSBjbGFzcyBt
YXkgYmUgaW1wbGVtZW50YXRpb24tZGVmaW5lZC4KPiA+Cj4gPiBbXSAzLjE3MiBGaWxlIE90aGVy
IENsYXNzCj4gPiBbXSBUaGUgcHJvcGVydHkgb2YgYSBmaWxlIGluZGljYXRpbmcgYWNjZXNzIHBl
cm1pc3Npb25zIGZvciBhCj4gPiBbXSBwcm9jZXNzIHJlbGF0ZWQgdG8gdGhlIHVzZXIgYW5kIGdy
b3VwIGlkZW50aWZpY2F0aW9uIG9mIGEgcHJvY2Vzcy4KPiA+IFtdIEEgcHJvY2VzcyBpcyBpbiB0
aGUgZmlsZSBvdGhlciBjbGFzcyBvZiBhIGZpbGUgaWYgdGhlIHByb2Nlc3MgaXMgbm90Cj4gPiBb
XSBpbiB0aGUgZmlsZSBvd25lciBjbGFzcyBvciBmaWxlIGdyb3VwIGNsYXNzLgo+ID4KPiA+IFRo
ZSBrZXkgZmFjdCBpbiB0aGVzZSBkZWZpbml0aW9ucyBpcyB0aGF0IGFuIGltcGxlbWVudGF0aW9u
IG1heSBkZWZpbmUKPiA+IGFkZGl0aW9uYWwgbWVtYmVycyBvZiB0aGUgRmlsZSBHcm91cCBDbGFz
cywgd2hpbGUgdGhlIG90aGVyIGNsYXNzZXMKPiA+IGFyZSBub3QgZXh0ZW5zaWJsZS4KPiA+Cj4g
PiBVbmRlciB0aGlzIGRlZmluaXRpb24sIHdlIGVuZCB1cCB3aXRoIHRoZSBmb2xsb3dpbmcgbWFw
cGluZzoKPiA+Cj4gPiAgLSBPV05FUkAgZW50cmllcyBhcmUgaW4gdGhlIEZpbGUgT3duZXIgQ2xh
c3MsCj4gPiAgLSBFVkVSWU9ORUAgZW50cmllcyBhcmUgaW4gdGhlIEZpbGUgT3RoZXIgQ2xhc3Ms
Cj4KPiBObywgSSBkb24ndCB0aGluayBFVkVSWU9ORUAgaXMgaW4gdGhlIEZpbGUgT3RoZXIgQ2xh
c3MuICBHaXZlbiB0aGlzIEFDTDoKPgo+IEVWRVJZT05FQDpyZWFkX2RhdGE6ZGVueQo+IE9XTkVS
QDpyZWFkX2RhdGE6YWxsb3cKPgo+IHRoZSBvd25lciB3b3VsZCBOT1QgYmUgYWJsZSB0byByZWFk
LiAgSW4gb3RoZXIgd29yZHMsIGZpbGUgb3duZXIKPiBjbGFzcyBhbmQgZmlsZSBncm91cCBjbGFz
cyBhcmUgYWxzbyBhZmZlY3RlZCBieSBFVkVSWU9ORUAgQUNFcy4KPgo+ID4gIC0gZXZlcnkgb3Ro
ZXIgZW50cnkgaXMgaW4gdGhlIEZpbGUgR3JvdXAgQ2xhc3MoKikuCj4KPiBpbmNsdWRpbmcgRVZF
UllPTkVALiAgOy0pCgpJIHN0cm9uZ2x5IGRpc2FncmVlLiBQbGVhc2UgcmVjb25zaWRlciB3aGF0
IEkgc2FpZCBhYm91dCBub24tbW9ub3RvbmljIApwZXJtaXNzaW9ucyBhbmQgIndlbGwgc3RydWN0
dXJlZCIgYWNscyAod2VsbC1mb3JtZWQgd291bGQgaGF2ZSBiZWVuIGEgYmV0dGVyIAp0ZXJtIGZv
ciBpdCk6CgogLSB3aXRoIHdlbGwtZm9ybWVkIEFDTHMsIHBlcm1pc3Npb25zIGZyb20gbXVsdGlw
bGUgY2xhc3NlcyBjYW5ub3QKICAgYWNjdW11bGF0ZS4KCiAtIHdpdGggYXJiaXRyYXJ5IEFDTHMs
IHBlcm1pc3Npb25zIGZyb20gbXVsdGlwbGUgY2xhc3NlcyBjYW4KICAgYWNjdW11bGF0ZS4gCgpU
aGUgd2VsbC1mb3JtZWRuZXNzIHByb3BlcnR5IG9mIGFuIEFDTCBkZXRlcm1pbmVzIHdoZXRoZXIg
b3Igbm90IHBlcm1pc3Npb25zIAptYXkgYWNjdW11bGF0ZSBhY3Jvc3MgY2xhc3Nlcy4gVGhpcyBk
b2VzIG5vdCBpbnZhbGlkYXRlIHRoZSBjbGFzc2lmaWNhdGlvbiAKaXRzZWxmLgoKV2hpbGUgYmVp
bmcgYSBwZXJmZWN0bHkgZmluZSBORlN2NCBBQ0wsIHRoZSBhYm92ZSBBQ0wgZGVmaW5pdGVseSBp
cyBub3QgCndlbGwtZm9ybWVkLgoKT3RoZXIgdGhhbiB0aGUgZmFjdCB0aGF0IHBlcm1pc3Npb25z
IG1heSBhY2N1bXVsYXRlIGFjcm9zcyBjbGFzc2VzICh3aGljaCBvbmx5IApiZWNvbWVzIGEgcHJv
YmxlbSB3aXRoIG5vbi1tb25vdG9uaWMgZmlsZSBtb2RlIHBlcm1pc3Npb24gYml0cyksICJpbGwt
Zm9ybWVkIiAKQUNMcyBhcmUgbm90IGEgcHJvYmxlbS4KCkZvciBzdHJpY3QgUE9TSVggY29tcGxp
YW5jZSwgd2UgbXVzdCBlbnN1cmUgdGhhdCBBQ0xzIGFyZSB3ZWxsLWZvcm1lZCBhZnRlciAKY2ht
b2QsIGFuZCB0aGF0IGluaGVyaXRlZCBBQ0xzIHdpbGwgYmUgd2VsbC1mb3JtZWQgYXMgd2VsbC4g
V2UgY291bGQgYWNoaWV2ZSAKdGhpcyBlaXRoZXIgYnkgcmVqZWN0aW5nICJpbGwtZm9ybWVkIiBB
Q0xzIGR1cmluZyBTRVRBVFRSIG9mIEFDTCAoc28gdGhhdCAKY2htb2QgYW5kIGluaGVyaXRlZCBw
ZXJtaXNzaW9ucyB3aWxsIGFsd2F5cyBvcGVyYXRlIG9uIHdlbGwtZm9ybWVkIGFjbHMpLCBvciAK
d2UgY291bGQgdHJ5IHRvIGNvbnZlcnQgYXJiaXRyYXJ5IEFDTHMgaW50byB3ZWxsLWZvcm1lZCBB
Q0xzIGR1cmluZyBjaG1vZCBhbmQgCmR1cmluZyBwZXJtaXNzaW9uIGluaGVyaXRhbmNlICgqKS4g
SSBhbSBzdXJlIHRoYXQgdGhlcmUgYXJlIHNvbWUgZm9ybXMgb2YgCk5GU3Y0IEFDTHMgd2hpY2gg
Y2Fubm90IGJlIGNvbnZlcnRlZCBpbnRvIHdlbGwtZm9ybWVkIEFDTHMgd2l0aG91dCBsb3NzIG9m
IAppbmZvcm1hdGlvbiwgc28gd2Ugd291bGQgaGF2ZSB0byBmYWlsIHNvbWUgY2htb2RzIGFuZCBm
aWxlIGNyZWF0ZXMuIFRoaXMgaXMgCnVnbHkgb2YgY291cnNlLCBhbmQgY2htb2QgZXJyb3JzIGlu
IHBhcnRpY3VsYXIgd291bGQgbW9zdCBsaWtlbHkgYmFkbHkgdHJhcCAKdXAgc29tZSBQT1NJWCBh
cHBsaWNhdGlvbnMuIEkgYW0gdW5kZWNpZGVkIHdoZXRoZXIgY2hlY2tpbmcgZm9yIHdlbGwtZm9y
bWVkIApBQ0xzIGluIFNFVEFUVFIgb3IgbWFzYWdlaW5nIEFDTHMgaW4gQ0hNT0QgYW5kIGR1cmlu
ZyBjcmVhdGVzIGlzIHRoZSBsZXNzZXIgCmV2aWwuCgooKikgSWxsLWZvcm1lZCBBQ0xzIGFyZSBv
bmx5IGFuIGlzc3VlIHdpdGggYSBub24tbW9ub3RvbmljIGNobW9kIG9yIGZpbGUgCmNyZWF0ZSBt
b2RlLiBUaGlzIG1lYW5zIHRoYXQgYWNsIGluaGVyaXRhbmNlIGFuZCBjaG1vZCBpcyBQT1NJWCBj
b21wbGlhbnQgCmV2ZW4gd2l0aCBpbGwtZm9ybWVkIEFDTHMgYXMgbG9uZyBhcyB0aGUgbW9kZSBp
cyBtb25vdG9uaWMsIGFuZCB3ZSBhY3R1YWxseSAKb25seSBuZWVkIHRvIGJlIGNhcmVmdWwgaW4g
dGhlIChhbG1vc3QgdW5yZWFsaXN0aWNhbGx5KSByYXJlIGNhc2Ugd2hlcmUgdGhlIAptb2RlIGlz
IG5vbi1tb25vdG9uaWMuCgpCZWNhdXNlIG9mIHRoZSByYW1pZmljYXRpb25zIG9mIHRyeWluZyB0
byBlbmZvcmNlIHdlbGwtZm9ybWVkIEFDTHMgb3IgdHJ5aW5nIAp0byBjb25zdHJ1Y3RpbmcgdGhl
bSBhZnRlciB0aGUgZmFjdCwgd2UgbWF5IHdhbnQgdG8gb2ZmZXIgdXNlcnMgYSBjaG9pY2UgdG8g
CnZpb2xhdGUgdGhpcyBwYXJ0aWN1bGFyIGFzcGVjdCBvZiBQT1NJWCBpbiBjZXJ0YWluIGluc3Rh
bGxhdGlvbnM6IGFjY29yZGluZyAKdG8gbXkgZXhwZXJpZW5jZSwgbm9uLW1vbm90b25pYyBwZXJt
aXNzaW9ucyBkbyBub3QgYWN0dWFsbHkgb2NjdXIgaW4gcmVhbCAKbGlmZSwgc28gSSBhbSBjb252
aW5jZWQgdGhhdCB0aGlzIGlzIG11Y2ggbGVzcyBldmlsIG9uIHVzZXJzIHRoYW4gdG90YWxseSAK
c3RyaWN0IFBPU0lYIGNvbXBsaWFuY2UuCgooVGhlIHJ1bGVzIGhvdyB3ZWxsLWZvcm1lZCBBQ0xz
IG11c3QgYmUgc3RydWN0dXJlZCBhcmUgcHJldHR5IHNpbXBsZS4gSSBkb24ndCAKd2FudCB0byBk
ZXRhaWwgdGhlbSBoZXJlIGF0IHRoaXMgcG9pbnQsIGJ1dCB0aGV5IGNhbiBiZSBkaXN0aWxsZWQg
ZnJvbSAKTWFyaXVzJ3MgZHJhZnQtaWV0Zi1uZnN2NC1hY2wtbWFwcGluZy0wNCBbM10uKQoKPiA+
ICAoKikgVXNlciBlbnRyaWVzIGZvciB0aGUgdXNlciB3aG8gaXMgdGhlIGN1cnJlbnQgZmlsZSBv
d25lciBhcmUgYQo+ID4gICAgICBzcGVjaWFsIGNhc2U6IGR1ZSB0byBob3cgdGhlIE5GU3Y0IEFD
TCBwZXJtaXNzaW9uIGNoZWNrIGFsZ29yaXRobQo+ID4gICAgICBpcyBzcGVjaWZpZWQsIEkgYmVs
aWV2ZSB0aGF0IHRoZXkgc2hvdWxkIGJlIHB1dCBpbiB0aGUgT1dORVJACj4gPiAgICAgIGNsYXNz
LiAKPgo+IFRoZSBjdXJyZW50IG1pbm9ydmVyc2lvbjEgZHJhZnQgaGFzIGEgc2ltaWxhciBkZXNp
Z24gY29uc3RyYWludC4KCi4uLiB3aGljaCBjb21lcyBlbnRpcmVseSBmcm9tIGRyYWZ0LWlldGYt
bmZzdjQtYWNscywgaWYgSSBhbSBub3QgbWlzdGFrZW4uCgo+ID4+IE5vdGUgdGhhdCB0aGlzIGRl
ZmluaXRpb24gaXMgaW4gbGluZSB3aXRoIFBPU0lYIDEwMDMuMWUgZHJhZnQgMTcKPiA+PiBbMl0s
IHdoaWxlIGl0IGNvbmZsaWN0cyB3aXRoIHRoZSBJRVRGIE5GUyBWZXJzaW9uIDQgQUNMcyBkcmFm
dCBbMV0sCj4gPj4gd2hpY2ggYXNzb2NpYXRlcyBvbmx5IEdST1VQQCBlbnRyaWVzIHdpdGggdGhl
IGdyb3VwIGZpbGUgbW9kZQo+ID4+IHBlcm1pc3Npb24gYml0cyBpbiBzZWN0aW9uIDUuMS4gVGhl
IHJlbGV2YW50IHRleHQgb2YgSUVURiBORlMKPiA+PiBWZXJzaW9uIDQgQUNMcyBkcmFmdCBbMV0g
aXMgYWxzbyBmb3VuZCBpbiBORlN2NCBNaW5vciBWZXJzaW9uIDEgWzRdLgo+ID4KPiA+IFNlY3Rp
b24gNS4xIG9mIFsxXSBuZWVkcyB0byBiZSBmaXhlZDogd2UgbXVzdCBzZXQgdGhlIHBlcm1pc3Np
b24KPiA+IGJpdHMgc28gdGhhdCB0aGV5IGFyZSBhIHN1cGVyc2V0IG9mIHRoZSBwZXJtaXNzaW9u
cyBvZiBhbGwgdGhlCj4gPiBlbnRyaWVzIGluIHRoZSByZXNwZWN0aXZlIGNsYXNzLiAoV2UgY2Fu
bm90IHJlcHJlc2VudCBwZXJtaXNzaW9ucyB0aGF0Cj4gPiBhcmUgbm90IHN1cGVyc2V0cyBvZiBQ
T1NJWCByZWFkLCB3cml0ZSwgZXhlY3V0ZSBpbiB0aGUgY2xhc3MsIGJ1dCB0aGF0Cj4gPiBpcyBu
b3QgYSBwcm9ibGVtLCBhcyB3ZSB3aWxsCj4gPiBzZWUgbGF0ZXIuKQo+Cj4gV2UgbXVzdCBkbyBz
byBjYXJlZnVsbHkuCgpObyBkb3VidCBhYm91dCBpdC4KCj4gSSdtIG5vdCBjb252aW5jZWQgdGhh
dCBhIHN1cGVyc2V0IGlzIHRoZSBiZXN0IHdheSB0byBnbywgYnV0IHdlIHNob3VsZCB0YWxrCj4g
YWJvdXQgdGhpcyBsYXRlci4gIAoKTm90aGluZyBlbHNlIG1ha2VzIGFueSBzZW5zZSBhdCBhbGwg
SU1PLCBhbmQgbm90aGluZyBlbHNlIHdvdWxkIGJlIGNvbXBhdGlibGUgCndpdGggUE9TSVggKGFz
IGZhciBhcyB0aGUgYWRkaXRpb25hbCBmaWxlIGFjY2VzcyBjb250cm9sIHBhcnQgZ29lcyksIG9y
IGluIAp0aGUgc3Bpcml0IG9mIFBPU0lYIChmb3IgdGhlIGFsdGVybmF0ZSBmaWxlIGFjY2VzcyBj
b250cm9sIHBhcnQpLiBJIHRoaW5rIEkgCmhhdmUgZ2l2ZW4gc3VmZmljaWVudCBhcmd1bWVudHMg
d2h5IHRoaXMgaXMgc28uCgo+ID4gTm9uLW1vbm90b25pYyBwZXJtaXNzaW9ucwo+ID4gPT09PT09
PT09PT09PT09PT09PT09PT09PQo+ID4KPiA+IE5vdGUgdGhhdCB3aXRoIGFyYml0cmFyeSBORlNW
NCBBQ0xzLCB0aGUgcGVybWlzc2lvbnMgZ3JhbnRlZCB0byBhCj4gPiBwcm9jZXNzIGZyb20gbXVs
dGlwbGUgQUNMIGVudHJpZXMgd2lsbCBhY2N1bXVsYXRlLiBUaGlzIG1lYW5zIHRoYXQKPiA+IHBl
cm1pc3Npb25zIGFjcm9zcyBtdWx0aXBsZSBjbGFzc2VzIG1heSBhY2N1bXVsYXRlIGFzIHdlbGwu
IFRoaXMgY2FuIGJlCj4gPiBwcmV2ZW50ZWQgd2l0aCBERU5ZIGVudHJpZXMgaW4gdGhlIEFDTCwg
ZS5nLiwKPiA+Cj4gPiAJT1dORVJAOm1hc2sxOjpBTExPVwo+ID4gCU9XTkVSQDpebWFzazE6OkRF
TlkKPiA+IAl1c2VyQGRvbWFpbjptYXNrMjo6QUxMT1cKPiA+IAlncm91cEBkb21haW46bWFzazM6
QUNFNF9JREVOVElGSUVSX0dST1VQOkFMTE9XCj4gPiAJdXNlckBkb21haW46Xm1hc2syOjpERU5Z
Cj4gPiAJZ3JvdXBAZG9tYWluOl5tYXNrMzpBQ0U0X0lERU5USUZJRVJfR1JPVVA6REVOWQo+ID4g
CUVWRVJZT05FOm1hc2s0OjpBTExPVwo+ID4KPiA+IFRoaXMgbWVhbnMgdGhhdCB3ZSB3aWxsIG5v
dCBoYXZlIHRvIGRlYWwgd2l0aCB0aGlzIHNwZWNpYWwgY2FzZQo+ID4gd2hlbiBjb21wdXRpbmcg
dGhlIGZpbGUgbW9kZSBwZXJtaXNzaW9uIGJpdHMsIGFuZCB3ZSBjYW4gYWNoaWV2ZQo+ID4gY29u
c2lzdGVuY3kgYnkgZm9yY2luZyBBQ0xzIHRvIGJlICJ3ZWxsIHN0cnVjdHVyZWQiLgo+Cj4gWXVj
ayEgIEknbSBnbGFkIHlvdSdyZSBub3QgcHJvcG9zaW5nIHRoaXMgYXMgYSBnZW5lcmFsIE5GU3Y0
IEFDTAo+IG1vZGVsLiAgOi0pCgpOb3RlIHRoYXQgdGhpcyBpcyBleGFjdGx5IGhvdyB0aGUgcHJv
cG9zZWQgc2l4LWVudHJ5IEFDTCBvbiBwYWdlIDE1IG9mIApkcmFmdC1pZXRmLW5mc3Y0LWFjbHMg
aXMgc3RydWN0dXJlZCwgYW5kIGhvdyBkcmFmdC1pZXRmLW5mc3Y0LWFjbC1tYXBwaW5nLTA0IApB
Q0xzIGFyZSBzdHJ1Y3R1cmVkLCBhbmQgbm90IGJ5IGNvaW5jaWRlbmNlLiBJIGFncmVlIGl0J3Mg
YSBiaXQgdWdseSwgYnV0IHRoZSAKYWNjdW11bGF0aXZlIHNlbWFudGljcyBvZiBORlN2NCBBQ0xz
IGRvbid0IGxlYXZlIHVzIGFueSBvdGhlciBvcHRpb25zLgoKPiA+IFdlIGNvdWxkIGFsc28gbGVh
dmUgdGhpcyBhcyBhbiBpbXBsZW1lbnRhdGlvbiBjb25zaWRlcmF0aW9uOiBBQ0xzCj4gPiB3aGlj
aCBhcmUgbm90ICJ3ZWxsIHN0cnVjdHVyZWQiIGluIHRoZSBhYm92ZSBzZW5zZSB3aWxsIGdyYW50
IHBlcm1pc3Npb25zCj4gPiB0aGF0IGdvIGJleW9uZCB3aGF0IGFuIGFkZGl0aW9uYWwgYWNjZXNz
IGNvbnRyb2wgbWVjaGFuaXNtIG1heSBncmFudAo+ID4gKm9ubHkqIGZvciBub24tbW9ub3Rvbmlj
IGZpbGUgbW9kZSBwZXJtaXNzaW9uIGJpdHMuIFdpdGggbm9uLW1vbm90b25pYyBJCj4gPiBtZWFu
ICBmaWxlIG1vZGUgcGVybWlzc2lvbiBiaXRzIHdoaWNoIGdyYW50IG1vcmUgcGVybWlzc2lvbnMg
dG8gdGhlIGdyb3VwCj4gPiBjbGFzcyB0aGFuIHRvIHRoZSBvd25lciBjbGFzcywgb3IgbW9yZSBw
ZXJtaXNzaW9ucyB0byB0aGUgb3RoZXIgY2xhc3MgdGhhbgo+ID4gdG8gdGhlIGdyb3VwIGNsYXNz
Lgo+Cj4gSSdtIHNvcnJ5LCBJIGp1c3QgZG9uJ3QgZm9sbG93IHRoYXQgcGFyYWdyYXBoLgoKSSBo
YXZlIGFscmVhZHkgdHJpZWQgdG8gcmVpdGVyYXRlIHRoaXMgcG9pbnQgZnVydGhlciB1cCBpbiB0
aGlzIHJlcGx5LiBTdGlsbCAKdW5jbGVhcj8KCj4gPj4gV2Ugd2FudCBjaG1vZCgyKSB0byBiZSBu
b24tZGVzdHJ1Y3RpdmUsIHNvIHRoYXQgYSBjaG1vZCB0byBhIG1vcmUKPiA+PiByZXN0cmljdGl2
ZSBtb2RlIGFuZCBiYWNrIHRvIHRoZSBvcmlnaW5hbCBtb2RlIHdpbGwgbGVhdmUgdGhlIGZpbGUK
PiA+PiB3aXRoIHRoZSBzYW1lIHBlcm1pc3Npb25zIGFzIGJlZm9yZSB0aGUgY2hhbmdlcy4KPiA+
Pgo+ID4+IFsuLi5dCj4gPj4KPiA+PiBQT1NJWCBBQ0xzIGhhdmUgc29sdmVkIHRoZSBub24tZGVz
dHJ1Y3RpdmVuZXNzIHByb2JsZW0gYnkgaW50cm9kdWNpbmcgYQo+ID4+IG1hc2sgQUNMIGVudHJ5
OiB0aGUgbWFzayBlbnRyeSBhcHBsaWVzIHRvIGFsbCBncm91cCBjbGFzcyBlbnRyaWVzLCBhbmQK
PiA+PiBkZWZpbmVzIGFuIHVwcGVyIGJvdW5kIHRvIHRoZSBwZXJtaXNzaW9ucyB0aG9zZSBlbnRy
aWVzIG1heSBncmFudC4gUE9TSVgKPiA+PiBBQ0xzIG9ubHkgaGF2ZSBBQ0wgZW50cmllcyB0aGF0
IGFsbG93IHBlcm1pc3Npb25zLCBhbmQgb25seSBzcGVjaWZ5IFJFQUQsCj4gPj4gV1JJVEUsIGFu
ZCBFWEVDVVRFIHBlcm1pc3Npb25zLiBUaGVyZWZvcmUsIHRoZSBvd25lciBjbGFzcyBhbmQgb3Ro
ZXIKPiA+PiBjbGFzcyBwZXJtaXNzaW9ucyBhcmUgdGhlIHBlcm1pc3Npb25zIGdyYW50ZWQgdG8g
dGhlIG93bmVyIGFuZCB0byBvdGhlcnMsCj4gPj4gcmVzcGVjdGl2ZWx5LiAoTm90ZSB0aGUgZGlm
ZmVyZW5jZSBiZXR3ZWVuIHRoZXNlIG90aGVycyBhbmQgTkZTdjQncwo+ID4+IEVWRVJZT05FQCBz
cGVjaWFsIGlkZW50aWZpZXIpLgo+ID4+Cj4gPj4gVGhlIG1hc2sgY29uY2VwdCBpcyBub3QgcGFy
dCBvZiBORlN2NCBBQ0xzLiBNYXJpdXMgQS4gRXJpa3NlbiBhbmQgb3RoZXJzCj4gPj4gaGF2ZSBw
cm9wb3NlZCB0byBlbXVsYXRlIHRoZSBQT1NJWCBBQ0wgbWFzayBlbnRyeSBieSBwcmVwZW5kaW5n
ICh3aXRoCj4gPj4gZXhjZXB0aW9uIG9mIE9XTkVSQCBhbmQgRVZFUllPTkVAIEFDRXMpIGVhY2gg
QUxMT1cgQUNFIHdpdGggYSBERU5ZCj4gPj4gQUNFIGZvciB0aGUgc2FtZSB1c2VyLCBncm91cCwg
b3Igc3BlY2lhbCBpZGVudGlmaWVyIGFzIGluIHRoZSBBTExPVyBBQ0UuCj4gPj4gVGhlIHBlcm1p
c3Npb25zIGluIHRoZSBERU5ZIEFDRSBhcmUgc2V0IHNvIHRoYXQgdGhlIGVudHJ5IGRlbmllcyB0
aGUKPiA+PiBwZXJtaXNzaW9ucyBub3QgZ3JhbnRlZCBieSB0aGUgbWFzay4KPiA+Cj4gPiBJbnRl
cm5ldCBkcmFmdC1pZXRmLW5mc3Y0LWFjbHMtMDAudHh0IFsxXSB1c2VzIHRoZSBzYW1lIG1lY2hh
bmlzbQo+ID4gdG8gaW1wbGVtZW50IG1hc2tpbmcuCj4gPgo+ID4+IFVubGVzcyB3ZSBhY2NlcHQg
YSB2ZXJ5IHNwZWNpZmljIGZvcm0gb2YgTkZTdjQgQUNMcyBvbmx5ICh3aGljaCB3b3VsZAo+ID4+
IGNvbnRyYWRpY3QgdGhlIGdvYWwgc3RhdGVkIGF0IHRoZSB0b3Agb2YgdGhpcyBtZXNzYWdlLCBh
bmQgd2hpY2gKPiA+PiB3b3VsZCBtZWFuIHRoYXQgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIGFueXRo
aW5nIGJ1dCBQT1NJWCBBQ0xzIHdvdWxkCj4gPj4gYmVjb21lIGRpZmZpY3VsdCksIHRoZXJlIGlz
IG5vIGVhc3kgd2F5IHRvIHRlbGwgREVOWSBlbnRyaWVzIGludHJvZHVjZWQKPiA+PiB0byBlbXVs
YXRlIHRoZSBtYXNrIGZyb20gREVOWSBlbnRyaWVzIGFkZGVkIGJ5IGhhbmQuCj4KPiBJIHdvdWxk
IHJlZnV0ZSB0aGlzOyBzZWUgYmVsb3cuCj4KPiA+PiBUaGlzIGhhcyB0d28gcG90ZW50aWFsIGNv
bnNlcXVlbmNlczoKPiA+Pgo+ID4+ICAtIEZpcnN0LCBpZiB3ZSBmYWlsIHRvIGlkZW50aWZ5IHN1
Y2ggYSBtYXNrLWVtdWxhdGlvbiBERU5ZIGVudHJ5LAo+ID4+ICAgIHdlIG1heSBlbmQgdXAgaW5z
ZXJ0aW5nIGFub3RoZXIgc3VjaCBlbnRyeS4gV2UgbWlnaHQgZW5kIHVwIGRvaW5nCj4gPj4gICAg
c28gcmVwZWF0ZWRseS4KPgo+IEJ1dCB3ZSB3aWxsIG5vdCBldmVyIGZhaWwgdG8gaWRlbnRpZnkg
c3VjaCBhIG1hc2stZW11bGF0aW9uIERFTlkKPiBlbnRyeSwgd2hlbiBpdCBpcyBvbmUgdGhhdCB3
YXMgY3JlYXRlZCBieSBhIHByZXZpb3VzIGNobW9kLiAgT25seSBpbgo+IGEgZGVnZW5lcmF0ZSBj
YXNlIG9mIG1vZGlmeS1hY2wtY2FyZWZ1bGx5LCBjaG1vZCwgbW9kaWZ5LWFjbC0KPiBjYXJlZnVs
bHksIGNobW9kLCBldGMuLCB3b3VsZCB5b3UgZ2V0IGEgZ3Jvd2luZyBBQ0wgcHJvYmxlbS4KClll
cy4gQW5kIGd1ZXNzIHdoYXQgd2lsbCBoYXBwZW4gd2hlbiBQT1NJWCBhbmQgV2luZG93cyBhcHBs
aWNhdGlvbnMgd2lsbCAKbW9kaWZ5IHRoZSBwZXJtaXNzaW9ucyBvZiB0aGUgc2FtZSBmaWxlIGlu
IHR1cm4/IE5vdGUgdGhhdCBldmVuIGEgY2htb2QgZnJvbSAKb25lIG1vZGUgdG8gYW5vdGhlciBh
bmQgYmFjayBpcyBlbm91Z2ggdG8gbWVzcyB0aGluZ3MgdXAgcXVpdGUgYmFkbHkuCgpBcyBmYXIg
YXMgSSByZW1lbWJlciwgV2luMksgYWx3YXlzIHJlb3JkZXJzIEFDTCBlbnRyaWVzIHNvIHRoYXQg
YWxsIERFTlkgCmVudHJpZXMgY29tZSBiZWZvcmUgYWxsIEFMTE9XIGVudHJpZXMuCgo+ID4+ICAt
IFNlY29uZCwgd2UgbWF5IHRha2UgYSB1c2VyLXByb3ZpZGVkIERFTlkgZW50cnkgZm9yIGEgbWFz
ay0KPiA+PiBlbXVsYXRpb24gREVOWSBlbnRyeSwgYW5kIGNsZWFyIG1hc2sgYml0cyBmcm9tIHRo
YXQgZW50cnkuIFRoaXMgd291bGQKPiA+PiBjb250cmFkaWN0IHRoZSB1c2VyJ3MgaW50ZW50aW9u
LiBTbyB0aGUgYXBwcm9hY2ggb2YgaW5zZXJ0aW5nCj4gPj4gbWFzay1lbXVsYXRpb24gREVOWSBl
bnRyaWVzIGlzIG5vdCBnb29kIGVub3VnaCBpbiBnZW5lcmFsLgo+Cj4gQSB1c2VyLXByb3ZpZGVk
IERFTlkgZW50cnkgd291bGQgaGF2ZSB0byBmaXQgaW50byBhIHZlcnkgc3BlY2lmaWMgYW5kCj4g
c29tZXdoYXQgbm9uc2Vuc2ljYWwgZm9ybSBpbiBvcmRlciB0byBiZSBtaXNpZGVudGlmaWVkLiAg
SGVyZSdzIGFuCj4gZXhhbXBsZToKPgo+IHNhbWZAc3VuLmNvbTpyZWFkX2RhdGE6ZGVueQo+IHNh
bWZAc3VuLmNvbTpyZWFkX2RhdGE6YWxsb3cKPgo+IElmIGEgImNobW9kIDQ0NCIgd2VyZSBkb25l
LCB0aGUgZGVueSBBQ0UgYWJvdmUgd291bGQgYmUgbW9kaWZpZWQuCj4gQW55IG90aGVyIGNhc2Vz
IG9mIGNobW9kIG1vZGlmeWluZyBhIHVzZXItcHJvdmlkZWQgQUNFIHdvdWxkIGhhdmUgdG8KPiBi
ZSBlc3NlbnRpYWxseSB0aGUgc2FtZSBhcyB0aGUgYWJvdmUgZXhhbXBsZS4gIEkgdGhpbmsgdGhh
dCB0aGF0J3MgYW4KPiBhY2NlcHRhYmxlIHNpdHVhdGlvbi4KCkkgYWxyZWFkeSBnYXZlIGEgbW9y
ZSByZWFsaXN0aWMgZXhhbXBsZSBhYm92ZToKCglHUk9VUEA6V1JJVEVfREFUQTo6REVOWQoJR1JP
VVBAOlJFQURfREFUQTo6QUxMT1cKCj4gPj4gKE1hcHBpbmcgYmV0d2VlbiBORlN2NCBhbmQgUE9T
SVggQUNMcyBkb2VzCj4gPj4gbm90IGhhdmUgdGhpcyBwcm9ibGVtLCBiZWNhdXNlIFBPU0lYIEFD
THMgZG9uJ3QgaGF2ZSBERU5ZIEFDRXMuKQo+ID4KPiA+IFRoZXJlZm9yZSwgdGhlIG1lY2hhbmlz
bSBkZXNjcmliZWQgaW4gc2VjdGlvbiA1LjMgaXMgbm90IHN1aXRhYmxlCj4gPiBmb3Igb3VyIHB1
cnBvc2VzLCBhbmQgd2UgbmVlZCB0byByZXBsYWNlIGl0IHdpdGggc29tZXRoaW5nIGJldHRlci4K
Pgo+IEkgZG9uJ3QgYWdyZWUgdGhhdCA1LjMgaXMgbm90IHN1aXRhYmxlLCBidXQgSSB3b3VsZCBs
b3ZlIHRvIHNlZQo+IHNvbWV0aGluZyBiZXR0ZXIuCgpXZWxsLCBJIGRpZCBwcm9wb3NlIHNvbWV0
aGluZyAqbXVjaCogYmV0dGVyLgoKPiA+PiBJbiBteSBvcGluaW9uLCB0aGVyZSBhcmUgdHdvIHBv
c3NpYmxlIHNvbHV0aW9ucyBmb3IgdGhpcyBwcm9ibGVtOgo+ID4+IHdlIGNhbiAoMSkgZGV2aXNl
IGEgc3BlY2lhbCBraW5kIG9mIE5GU3Y0IEFDTCBlbnRyeSB0aGF0IHdlIHdpbGwKPiA+PiByZWNv
Z25pemUgYXMgbWFzayBlbnRyeSwgb3IgKDIpIGdpdmUgdGhlIG93bmVyL2dyb3VwL290aGVyIGNs
YXNzCj4gPj4gcGVybWlzc2lvbiBiaXRzIGhpZ2hlciBwcmlvcml0eSB0aGFuIHRoZSBBQ0wgZW50
cmllcywgYW5kIG9ubHkgYWxsb3cKPiA+PiBwZXJtaXNzaW9ucyB0aGF0IGFyZSBhbGxvd2VkIGJ5
IGJvdGggdGhlIEFDRXMgYW5kIHRoZWlyIGFzc29jaWF0ZWQKPiA+PiBjbGFzc2VzLiAKPgo+IFlp
a2VzIC0tIEkgZG9uJ3QgbGlrZSBlaXRoZXIgb2YgdGhlIGFib3ZlIHNvbHV0aW9uczsgbGV0J3Mg
bG9vayBhdAo+IHRoZSB0aGlyZC4uLgo+Cj4gPiBBIHRoaXJkIG9wdGlvbiBleGlzdHMgYXMgd2Vs
bCB3aGljaCBmaXRzIGluIHZlcnkgd2VsbCB3aXRoIFBPU0lYCj4gPiBhbmQgY2FuIGJlIGltcGxl
bWVudGVkIGluIE5GU3Y0IGluIGEgYmFja3dhcmQgY29tcGF0aWJsZSB3YXkuCj4gPgo+ID4gQWx0
ZXJuYXRpdmUgUHJvcG9zYWwKPiA+ID09PT09PT09PT09PT09PT09PT09Cj4gPgo+ID4gSW5zdGVh
ZCBvZiBhZGRpbmcgREVOWSBlbnRyaWVzIHRvIHRoZSBBQ0wgZm9yIHRoZSBwdXJwb3NlIG9mIG1h
c2tpbmcsCj4gPiBhdHRhY2ggdGhyZWUgb3B0aW9uYWwgYXR0cmlidXRlcyB0byBlYWNoIGZpbGU6
IG93bmVyX2NsYXNzX21hc2ssCj4gPiBncm91cF9jbGFzc19tYXNrLCBhbmQgb3RoZXJfY2xhc3Nf
bWFzay4gV2hlbiB0aG9zZSBhdHRyaWJ1dGVzIGFyZSBwcmVzZW50LAo+ID4gdGhleSBkZWZpbmUg
d2hpY2ggcGVybWlzc2lvbnMgaW4gYW4gQUNFIGFyZSBlZmZlY3RpdmUuCj4gPgo+ID4gRWFjaCBB
Q0UgaXMgaXMgcmVzdHJpY3RlZCBieSBvbmUgb2YgdGhlc2UgbWFzayBhdHRyaWJ1dGVzIGluIGVh
Y2gKPiA+IGFjY2VzcyBjaGVjazoKPiA+Cj4gPiAgLSBPV05FUkAgZW50cmllcyBhbmQgZW50cmll
cyBmb3IgdGhlIHVzZXJAZG9tYWluIHRoYXQgY3VycmVudGx5Cj4gPiAgICBvd25zIHRoZSBmaWxl
IGFyZSByZXN0cmljdGVkIGJ5IG93bmVyX2NsYXNzX21hc2suCj4gPgo+ID4gIC0gRVZFUllPTkVA
IGVudHJpZXMgYXJlIHJlc3RyaWN0ZWQgYnkgb3RoZXJfY2xhc3NfbWFzay4KPiA+Cj4gPiAgLSBB
bGwgb3RoZXIgZW50cmllcyBhcmUgcmVzdHJpY3RlZCBieSBncm91cF9jbGFzc19tYXNrLgo+ID4K
PiA+IFRoZSBlZmZlY3RpdmUgcGVybWlzc2lvbnMgYXJlIGNvbXB1dGVkIGFzIHRoZSBiaXR3aXNl
IGFuZCAoJikgb2YKPiA+IHRoZSBBQ0UgbWFzayBhbmQgdGhlIGFzc29jaWF0ZWQgY2xhc3NfbWFz
ayBhdHRyaWJ1dGUuCj4KPiBJIHRha2UgaXQgeW91IG1lYW4gdGhhdCAidGhlIGVmZmVjdGl2ZSBh
Y2Nlc3MgbWFzayBiaXRzIGZvciBBQ0VzIG9mCj4gdHlwZSBBTExPVyI/CgpXaGVuIGRldGVybWlu
aW5nIGFjY2VzcywgaXQgaXMgaXJyZWxldmFudCB3aGV0aGVyIHdlIG1hc2sgb25seSBBTExPVyBl
bnRyaWVzLCAKb3IgQUxMT1cgYW5kIERFTlkgZW50cmllcy4gV2hlbiBjb21wdXRpbmcgdGhlIG1h
c2sgYXR0cmlidXRlcywgd2UgbXVzdCBvbmx5IApjb25zaWRlciBBTExPVyBlbnRyaWVzIHRob3Vn
aC4KCj4gPiBXaGVuIGRvaW5nIGEgY2htb2QoMikgb3Igd2hlbiBhcHBseWluZyBhIGNyZWF0ZSBt
YXNrLCB0aGUKPiA+IG93bmVyX2NsYXNzX21hc2ssIGdyb3VwX2NsYXNzX21hc2ssIGFuZCBvdGhl
cl9jbGFzc19tYXNrIGF0dHJpYnV0ZXMgYXJlCj4gPiBtb2RpZmllZCBhY2NvcmRpbmcgdG8gdGhl
IG93bmVyIGNsYXNzLCBncm91cCBjbGFzcywgYW5kIG90aGVyIGNsYXNzCj4gPiBwZXJtaXNzaW9u
cyBvZiB0aGUgbW9kZSBwYXJhbWV0ZXIgYXMgZm9sbG93czoKPiA+Cj4gPiAgLSBUaGUgUE9TSVgg
cmVhZCBwZXJtaXNzaW9uIGltcGxpZXMgdGhlIEFDRTRfUkVBRF9EQVRBLAo+ID4gICAgQUNFNF9S
RUFEX0FUVFJJQlVURVMsIEFDRTRfUkVBRF9BQ0wsIGFuZCBBQ0U0X1NZTkNIUk9OSVpFIGJpdG1h
c2sKPiA+ICAgIGZsYWdzLiAKPiA+Cj4gPiAgLSBUaGUgUE9TSVggd3JpdGUgcGVybWlzc2lvbiBp
bXBsaWVzIHRoZSBBQ0U0X1dSSVRFX0RBVEEsCj4gPiAgICBBQ0U0X0FQUEVORF9EQVRBLCBBQ0U0
X1dSSVRFX0FUVFJJQlVURVMsIEFDRTRfREVMRVRFX0NISUxELCBhbmQKPiA+ICAgIEFDRTRfU1lO
Q0hST05JWkUgYml0bWFzayBmbGFncy4KPgo+IEknbSBub3Qgc3VyZSBJIGFncmVlIGFib3V0IEFD
RTRfV1JJVEVfQVRUUklCVVRFUywgYnV0IHRoYXQncyBhIG1pbm9yCj4gZGV0YWlsLgoKSSBhZ3Jl
ZSB0aGF0IFBPU0lYIHdyaXRlIGRvZXMgbm90IGltcGx5IEFDRTRfV1JJVEVfQVRUUklCVVRFUy4K
Cj4gPiAgLSBUaGUgUE9TSVggZXhlY3V0ZSBwZXJtaXNzaW9uIGltcGxpZXMgdGhlIEFDRTRfRVhF
Q1VURSBtYXNrLgo+ID4KPiA+IFRoaXMgc2F2ZXMgdXMgZnJvbSBibG9hdGluZyBBQ0xzIHdpdGgg
REVOWSBlbnRyaWVzLCBpcyBtb3JlCj4gPiBlZmZpY2llbnQgd2hlbiBkb2luZyBhIGNobW9kLCBh
bmQgYWxzbyBzYXZlcyB1cyBmcm9tIGRlc3Ryb3lpbmcKPiA+IHBlcm1pc3Npb25zIGluIHVzZXIg
cHJvdmlkZWQgREVOWSBlbnRyaWVzLgo+Cj4gWWVzLCBidXQgYXQgdGhlIGNvc3Qgb2YgYWRkaW5n
IG5ldyBmaWxlIGF0dHJpYnV0ZXMuLi4gIERvbid0IGdldCBtZQo+IHdyb25nLCBJIGRvIHNlZSBt
ZXJpdCBpbiB0aGlzIHByb3Bvc2FsLCBidXQgSSBkb24ndCBrbm93IGlmIGl0J2xsIGJlCj4gYWNj
ZXB0YWJsZS4KCklmIHRoZSBudW1iZXIgb2YgYXR0cmlidXRlcyBpcyBhIGNvbmNlcm4sIHdlIGNv
dWxkIGVxdWFsbHkgd2VsbCBzdG9yZSBhbGwgCnRocmVlIG1hc2tzIGluIGEgc2luZ2xlIHRocmVl
LWVudHJ5IGFycmF5LgoKPiA+IFdoZW4gYW4gQUNMIGlzIHNldCwgdGhlbiBzZXQgYWxsIG1hc2sg
YXR0cmlidXRlcyB0byB0aGUgdmFsdWVzCj4gPiBwcm92aWRlZCBpbiB0aGUgc2FtZSBTRVRBVFRS
IG9wZXJhdGlvbiwgYW5kIHNldCB0aGUgcmVtYWluaW5nIG1hc2sKPiA+IGF0dHJpYnV0ZXMgdG8g
dGhlIHVuaW9uIG9mIGFsbCBBTExPVyBBQ0wgZW50cmllcyBpbiB0aGUgQUNMIHRoYXQgdGhlCj4g
PiBjbGFzcyBhcHBsaWVzIHRvLiAKPgo+IFRoaXMgZG9lc24ndCB0YWtlIHRoZSBvcmRlcmluZyBv
ZiB0aGUgQUNMIGludG8gYWNjb3VudDsgaXMgdGhpcyB5b3VyCj4gaW50ZW50aW9uPyAgU28KPgo+
IEdST1VQQDpyZWFkX2RhdGEvd3JpdGVfZGF0YTpERU5ZCj4gR1JPVVBAOnJlYWRfZGF0YS93cml0
ZV9kYXRhOkFMTE9XCj4KPiB3b3VsZCByZXN1bHQgaW4gYSBncm91cF9jbGFzc19tYXNrIG9mIHJl
YWRfZGF0YXx3cml0ZV9kYXRhLCByaWdodD8KPiAoSSdtIG5vdCBzYXlpbmcgaXQncyB3cm9uZywg
SSdtIGp1c3QgbWFraW5nIHN1cmUgSSB1bmRlcnN0YW5kLikKClllcywgb3JkZXIgaXMgaXJyZWxl
dmFudC4gTm90ZSB0aGF0IHdlIG11c3Qgb25seSBjb25zaWRlciB0aGUgQUxMT1cgZW50cmllcyAK
d2hlbiBjb21wdXRpbmcgb25lIG9mIHRoZSBtYXNrIGF0dHJpYnV0ZXMgdGhvdWdoLgoKPiA+IFdp
dGhvdXQgYW55IGZ1cnRoZXIgY2hhbmdlcywgTkZTdjQgY2xpZW50cyBub3QgYXdhcmUgb2YgdGhl
IHRocmVlCj4gPiBvcHRpb25hbCBhdHRyaWJ1dGVzIHdvdWxkIG5vdCBiZSBhd2FyZSBvZiB0aGUg
cmVzdHJpY3Rpb25zIGltcG9zZWQKPiA+IGJ5IHRob3NlIG1hc2tzIHdoZW4gcXVlcnlpbmcgZm9y
IHRoZSBBQ0wuIFRoaXMgd291bGQgY3JlYXRlIGFuCj4gPiBpbnRlcm9wZXJhYmlsaXR5IHByb2Js
ZW0sIGFuZCBwb3NzaWJsZSBzZWN1cml0eSBob2xlcy4gVG8gc29sdmUgdGhpcwo+ID4gcHJvYmxl
bSwgd2UgY2FuIGV4dGVuZCB0aGUgR0VUQVRUUgo+ID4gb3BlcmF0aW9uIGFzIGZvbGxvd3M6Cj4g
Pgo+ID4gV2hlbiBhIGNsaWVudCByZXF1ZXN0cyB0aGUgQUNMIGF0dHJpYnV0ZSwgY2hlY2sgaWYg
aXQgYWxzbyByZXF1ZXN0cwo+ID4gb25lIG9yIG1vcmUgb2YgdGhlIHRocmVlIG9wdGlvbmFsIG93
bmVyX2NsYXNzX21hc2ssIGdyb3VwX2NsYXNzX21hc2ssCj4gPiBvciBvdGhlcl9jbGFzc19tYXNr
IGF0dHJpYnV0ZXMuIElmIGl0IGRvZXMsIHRoZW4gc2VuZCB0aGUgcmVxdWVzdGVkCj4gPiBhdHRy
aWJ1dGVzIGFzIHRoZXkgYXJlLiBJZiB0aGUgY2xpZW50IHJlcXVlc3RzIG9ubHkgdGhlIEFDTCB3
aXRob3V0Cj4gPiBhbnkgb2YgdGhlIG1hc2tzLCByZXR1cm4gYW4gQUNMIHdpdGggb25seSBlZmZl
Y3RpdmUgbWFzayBmbGFncyBzZXQsCj4gPiBhbmQgd2l0aCBhbGwgb3RoZXIgZmxhZ3MgcmVtb3Zl
ZC4KPgo+IEkgYXNzdW1lIHlvdSBtZWFuIGluIHRoZSBBTExPVyBBQ0VzIG9ubHksIHJpZ2h0PwoK
UHJvYmFibHkgbm90OiB0aGUgcmVzdWx0aW5nIEFDTCB3aWxsIGdyYW50IGV4YWN0bHkgdGhlIHNh
bWUgcGVybWlzc2lvbnMgZWl0aGVyIAp3YXkuIFRoZSB3aG9sZSBBQ0wgd2lsbCBiZWNvbWUgZWFz
aWVyIHRvIHVuZGVyc3RhbmQgaWYgd2UgYWxzbyByZW1vdmUgbWFza2VkIApwZXJtaXNzaW9ucyBm
cm9tIERFTlkgQUNMIGVudHJpZXMsIHNvIHRoYWlzIGlzIHdoeSBJIHdvdWxkIHByZWZlciB0aGlz
IAphcHByb2FjaC4KCj4gPiBBbHRlcm5hdGUgcGVybWlzc2lvbnMgaW4gdGhlIEFDTCBjYW4gYmUg
ZW5hYmxlZCBieSBlaXRoZXIgc2V0dGluZwo+ID4gYW4gQUNMIHdpdGhvdXQgcHJvdmlkaW5nIGZ1
bGwgbWFzayBlbnRyaWVzLCBvciBieSBzZXR0aW5nIHRoZQo+ID4gYXBwcm9wcmlhdGUgYml0KHMp
IGluIHRoZSBjb3JyZXNwb25kaW5nIG1hc2sgZW50cnkgb3IgZW50cmllcy4KPgo+IFllcywgSSB0
aGluayBJIHVuZGVyc3RhbmQuCj4KPiA+IFdoZW4gY29tcGFyaW5nIFBPU0lYIEFDTHMgYW5kIHRo
ZSBORlN2NCBBQ0wgKyBtYXNrIGF0dHJpYnV0ZXMgYXMKPiA+IHByb3Bvc2VkIGhlcmUsIG9uZSBv
YnZpb3VzIGRpZmZlcmVuY2UgaXMgdGhhdCBQT1NJWCBBQ0xzIGhhdmUgb25seQo+ID4gb25lIG1h
c2sgZW50cnksIHdoaWxlIEkgcHJvcG9zZSB0aHJlZSBtYXNrIGVudHJpZXMgaGVyZS4gVGhlIHJl
YXNvbgo+ID4gZm9yIHRoaXMgaXMgdGhhdCBQT1NJWCBBQ0xzIGNhbiBhdCBtb3N0IGdyYW50IHJl
YWQsIHdyaXRlLCBhbmQKPiA+IGV4ZWN1dGUgcGVybWlzc2lvbnMsIGFuZCBzbyB3aXRoIFBPU0lY
IEFDTHMsIHRoZSBGaWxlIE93bmVyIENsYXNzCj4gPiBwZXJtaXNzaW9ucyBhcmUgYWx3YXlzIGlk
ZW50aWNhbCB0byB0aGUgcGVybWlzc2lvbnMgZ3JhbnRlZCB0byB0aGUKPiA+IG93bmVyLCBhbmQg
dGhlIEZpbGUgT3RoZXIgQ2xhc3MgcGVybWlzc2lvbnMgYXJlIGFsd2F5cyBpZGVudGljYWwgdG8K
PiA+IHRoZSBwZXJtaXNzaW9ucyBncmFudGVkIHRvIG90aGVycy4gV2l0aCBORlN2NCBBQ0xzLCBP
V05FUkAgYW5kCj4gPiBFVkVSWU9ORUAgZW50cmllcyBtYXkgZ3JhbnQgYWRkaXRpb25hbCBwZXJt
aXNzaW9ucyB0aGF0IGdvIGJleW9uZAo+ID4gd2hhdCBQT1NJWCByZWFkLCB3cml0ZSwgYW5kIGV4
ZWN1dGUgY2FuIGdyYW50LCBhbmQgd2UgbmVlZCBhCj4gPiBtZWNoYW5pc20gc28gdGhhdCB0aG9z
ZSBhbHRlcm5hdGUgcGVybWlzc2lvbnMgY2FuIGJlIHR1cm5lZCBvZmYgYnkKPiA+IGNobW9kIGFu
ZCBkdXJpbmcgZmlsZSBjcmVhdGUgd2l0aG91dCBkZXN0cm95aW5nIHRoZSBwZXJtaXNzaW9ucy4K
Pgo+IEdpdmVuIHRoYXQgRVZFUllPTkVAIGlzIG5vdCBlcXVpdmFsZW50IHRvIHRoZSBQT1NJWCAi
b3RoZXIiIGNsYXNzLCBpdAo+IGNvdWxkIGJlIHRyaW1tZWQgZG93biB0byB0d28uCgpTZWUgdGhl
IHdlbGwtZm9ybWVkIEFDTCBkaXNjdXNzaW9uIGFib3ZlIHdoeSBFVkVSWU9ORUAgc2hvdWxkIGJl
IGluIHRoZSBGaWxlIApPdGhlciBDbGFzcy4gQnV0IGV2ZW4gaWYgeW91IHRvdGFsbHkgb2JqZWN0
IHRvIHRoaXMgbGluZSBvZiBhcmd1bWVudGF0aW9uLCAKdGhlIEZpbGUgT3RoZXIgQ2xhc3Mgd291
bGQgc3RpbGwgbmVlZCB0byByZXN0cmljdCBFVkVSWU9ORUAgZW50cmllczogYWxsIAp1c2VycyBv
dGhlciB0aGFuIHRoZSBvd25lciwgb3duaW5nIGdyb3VwLCBvciBvdGhlciB1c2VycyBleHBsaWNp
dGx5IG1lbnRpb25lZCAKaW4gdGhlIEFDTCB3aWxsIGJlIGdyYW50ZWQgRVZFUllPTkVAIHBlcm1p
c3Npb25zLCBhbmQgd2UgbXVzdCBtYWtlIHN1cmUgdGhhdCAKbm8gdXNlciBpbiB0aGUgRmlsZSBP
dGhlciBDbGFzcyB3aWxsIG9idGFpbiBhbnkgcGVybWlzc2lvbnMgYmV5b25kIHRoZSBGaWxlIApP
dGhlciBDbGFzcyBwZXJtaXNzaW9ucyBhZnRlciBhIGNobW9kIHRvIGJlIFBPU0lYIGNvbXBsaWFu
dC4gKEFsdGVybmF0aXZlbHksIAp3ZSBjb3VsZCByZW1vdmUgcGVybWlzc2lvbnMgZGlyZWN0bHkg
ZnJvbSBhbGwgRVZFUllPTkVAIGVudHJpZXMsIGJ1dCB0aGF0IAp3b3VsZCBiZSBkZXN0cnVjdGl2
ZSwgd2hpY2ggaXMgZXhhY3RseSB3aGF0IHdlIGFyZSB0cnlpbmcgdG8gYXZvaWQuCgo+ID4gSSB3
b3VsZCBhcHByZWNpYXRlIGlmIHlvdSBjb3VsZCB0YWtlIHRoaXMgYWx0ZXJuYXRpdmUgcHJvcG9z
YWwgaW50bwo+ID4gY29uc2lkZXJhdGlvbiB3aGVuIGRlY2lkaW5nIGhvdyB0byBwcm9jZWVkIHdp
dGggTkZTdjQgTWlub3IKPiA+IFZlcnNpb24gMSBhdCBuZXh0IHdlZWsncyBJRVRGIDY2IG1lZXRp
bmcuCj4KPiBUaGlzIHByb3Bvc2FsIGNlcnRhaW5seSBoYXMgaXRzIG1lcml0cy4gIEkgaGF2ZSBk
b3VidHMgYWJvdXQgdGhlCj4gZmVhc2liaWxpdHkgb2YgYWRkaW5nIHR3byBvciB0aHJlZSBuZXcg
ZmlsZSBhdHRyaWJ1dGVzLCBhbmQgbmV3IGFzLQo+IHlldC11bmltcGxlbWVudGVkIHNlbWFudGlj
cywKCkNvbWUgb24sIGl0J3Mgbm90IGZhaXIgdG8gcHVsbCB0aGUgImFzLXlldC11bmltcGxlbWVu
dGVkIiBjYXJkLiBJIGFtIGRvaW5nIG15IApiZXN0IHRvIGFyZ3VlIG15IHBvaW50cyBhcyBleGhh
dXN0aXZlbHkgYXMgcG9zc2libGUuIEkgYWxzbyBoYXZlIHRoaXMgCnByb3Bvc2FsIGltcGxlbWVu
dGVkLCBhbmQgSSB3aWxsIHN0YXJ0IHNoYWtpbmcgb3V0IGJ1Z3MgdG9tb3Jyb3cuIEkgY2FuIG1h
a2UgCnRoZSBwcm90b3R5cGUgYXZhaWxhYmxlIHB1YmxpY2x5IGltbWVkaWF0ZWx5IGluIGNhc2Ug
eW91IGRvdWJ0IG1lLiBNeSBwbGFuIAp3YXMgdG8gZG8gc28gbGF0ZXIgdGhpcyB3ZWVrLCBhZnRl
ciBzb21lIG1vcmUgZGVidWdnaW5nLCB0aG91Z2guIEkgd2lsbCAKZGVmaW5pdGVseSBkbyBldmVy
eXRoaW5nIEkgY2FuIHRvIHJlbGVhc2UgYW4gaW5pdGlhbCB2ZXJzaW9uIHdpdGhpbiB0aGUgbmV4
dCAKZGF5cy4KCj4gaW50byB0aGUgbWlub3J2ZXJzaW9uMSBkcmFmdC4gIEkgaGF2ZSBkb3VidHMg
YWJvdXQgaG93IHRoaXMgd291bGQgYmUKPiBpbXBsZW1lbnRlZCBvbiBhIFdpbmRvd3MtYmFzZWQg
c2VydmVyLiAKCk5vdCBhdCBhbGwuICBXaW5kb3dzIHNlcnZlciBzaW1wbHkgd29uJ3QgaW1wbGVt
ZW50IHRoZSBtYXNrIGF0dHJpYnV0ZXMsIGFuZCBzbyAKdGhleSB3b3VsZCBzZWUgYSBwZXJmZWN0
IE5GU3Y0IEFDTCB3b3JsZC4gU29tZSBwZXJtaXNzaW9ucyB3aWxsIGdldCBrbm9ja2VkIApvdXQg
aWYgdGhlIEFDTCBjb250YWlucyBzb21lIGFsdGVybmF0aXZlIHBlcm1pc3Npb25zIGFuZCB0aGUg
VU5JWCBzaWRlIGxhdGVyIApkaXNhYmxlcyB0aGVtLCBvciBpZiB0aGUgQUNMIGNvbnRhaW5zIHNv
bWUgcGVybWlzc2lvbnMgdGhhdCB0aGUgVU5JWCBzaWRlIApkZWNpZGVzIHRvIG1hc2suIFRoaXMg
aXMgKm9ubHkqIGFuIGlzc3VlIHdoZW4gYSBXaW5kb3dzIHN5c3RlbSBtb2RpZmllcyB0aGUgCnBl
cm1pc3Npb25zIG9mIGEgZmlsZSBhZnRlciBzb21lIHBlcm1pc3Npb25zIGhhdmUgYmVlbiBtYXNr
ZWQgYnkgYSBQT1NJWCAKc3lzdGVtICh3aGljaCBtZWFucyB0aGF0IHRoZSBQT1NJWCBzeXN0ZW0g
bXVzdCBoYXZlIG1vZGlmaWVkIHRoZSBwZXJtaXNzaW9ucyAKb2YgdGhlIHNhbWUgZmlsZSBhcyB3
ZWxsKS4gSW4gcGFydGljdWxhciwgaXQgaXMgbm90IGFuIGlzc3VlIHdoZW4gb25seSAKV2luZG93
cyBzeXN0ZW1zIGFjY2VzcyBhIGZpbGUsIG9yIHdoZW4gb25seSBQT1NJWCBzeXN0ZW1zIGFjY2Vz
cyBhIGZpbGUuCgo+IFRoZSBjdXJyZW50IGRlc2lnbiBzcGVjaWZpZWQgaW4gZHJhZnQtaWV0Zi1u
ZnN2NC1taW5vcnZlcnNpb24xLTAzLnR4dAo+IGhhcyBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNl
IC0tIGl0J3MgcmVsZWFzZWQgaW4gU29sYXJpcyAxMCB1cGRhdGUKPiAzLCBhIHNoaXBwaW5nIHBy
b2R1Y3QuIEl0IG1lZXRzIHN0cmljdCBQT1NJWCByZXF1aXJlbWVudHMgZm9yIHRob3NlCj4gaW1w
bGVtZW50YXRpb25zIHRoYXQgY2hvb3NlIHRvIGNvbmZvcm0gdG8gUE9TSVguICAKCkl0IGlzICpu
b3QqIFBPU0lYIGNvbXBsaWFudCB1bmxlc3MgaXQgaW1wbGVtZW50cyBhIGZldyB0aGluZ3Mgb3Ro
ZXIgdGhhbiAKZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYtbmZzdjQtYWNscy0wMC4gSSBoYXZlIGFy
Z3VlZCB3aHkgaW4gdGhlIGZpcnN0IHBhcnQgb2YgCm15IHJlcGx5LgoKPiBJIGJlbGlldmUgaXQn
cyBmdWxseSBpbXBsZW1lbnRhYmxlIG9uIGEgV2luZG93cy1iYXNlZCBzZXJ2ZXIuCgpXaHkgc2hv
dWxkIE1pY3Jvc29mdCBzcGVuZCB0aW1lIG9uIGRyYWZ0LWlldGYtbmZzdjQtYWNscy0wMCBvdGhl
ciB0aGFuIGZvciAKY29tcHV0aW5nIHJlYXNvbmFibGUgZmlsZSBtb2RlcygqKik/IE5GU3Y0IEFD
THMgYXJlIE5URlMvQ0lGUyBBQ0xzIG1pbnVzIApBdXRvbWF0aWMgSW5oZXJpdGFuY2UgKHNlZSAK
aHR0cDovL3d3dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZnN2NC9jdXJyZW50L21zZzAz
MTM1Lmh0bWwpCgooKiopIEkgYWxyZWFkeSBhcmd1ZSB3aHkgdGhlIGFsZ29yaXRobSBpbiBzZWN0
aW9uIDUuMSBvZiAKZHJhZnQtaWV0Zi1uZnN2NC1hY2xzLTAwIGlzIHdyb25nIGFuZCBub3QgUE9T
SVggY29tcGxpYW50LiBUaGlzIGNhbiBlYXNpbHkgYmUgCmZpeGVkLCBidXQgaG93IGl0IHNob3Vs
ZCBiZSBmaXhlZCBkZXBlbmRzIG9uIHdoaWNoIGFwcHJvYWNoIGlzIGNob3Nlbi4KCgpUaGFua3Ms
CkFuZHJlYXMKCj4gPj4gUkVGRVJFTkNFUwo+ID4+Cj4gPj4gWzFdIFNhbSBGYWxrbmVyIGV0IGFs
LjogTkZTIFZlcnNpb24gNCBBQ0xzLCBkcmFmdC1pZXRmLW5mc3Y0LQo+ID4+IGFjbHMtMDAudHh0
Cj4gPj4KPiA+PiBbMl0gUE9TSVggMTAwMy4xZS8yYyBkcmFmdCAxNyAod2l0aGRyYXduKSwKPiA+
PiBodHRwOi8vd3QueHBpbG90Lm9yZy9wdWJsaWNhdGlvbnMvcG9zaXguMWUKPiA+Pgo+ID4+IFsz
XSBNYXJpdXMgQWFtb2R0IEVyaWtzZW4gZXQgYWwuOiBNYXBwaW5nIEJldHdlZW4gTkZTdjQgYW5k
IFBvc2l4Cj4gPj4gRHJhZnQKPiA+PiBBQ0xzLCBkcmFmdC1pZXRmLW5mc3Y0LWFjbC1tYXBwaW5n
LTA0LnR4dAo+ID4+Cj4gPj4gWzRdIFNwZW5jZXIgU2hlcGxlciAoZWRpdG9yKTogTkZTdjQgTWlu
b3IgVmVyc2lvbiAxLAo+ID4+IGRyYWZ0LWlldGYtbmZzdjQtbWlub3J2ZXJzaW9uMS0wMy50eHQK
Cls1XSBTdGFuZGFyZCBmb3IgSW5mb3JtYXRpb24gVGVjaG5vbG9neSDigJQgUG9ydGFibGUgT3Bl
cmF0aW5nIFN5c3RlbSBJbnRlcmZhY2UgCihQT1NJWMKuKSwgaHR0cDovL3d3dy5vcGVuZ3JvdXAu
b3JnL2F1c3Rpbi8KCls2XSBBbmRyZWFzIEdydWVuYmFjaGVyOiBQT1NJWCBBY2Nlc3MgQ29udHJv
bCBMaXN0cyBvbiBMaW51eCwgCmh0dHA6Ly93d3cuc3VzZS5kZS9+YWdydWVuL2FjbC9saW51eC1h
Y2xzLwoKWzddIFBPU0lYIDEwMDMuMWUvMmMgZHJhZnQgMTcsIGh0dHA6Ly93dC54cGlsb3Qub3Jn
L3B1YmxpY2F0aW9ucy9wb3NpeC4xZS8KCi0tIApBbmRyZWFzIEdydWVuYmFjaGVyIDxhZ3J1ZW5A
c3VzZS5kZT4KTm92ZWxsIC8gU1VTRSBMYWJzCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpVc2luZyBUb21j
YXQgYnV0IG5lZWQgdG8gZG8gbW9yZT8gTmVlZCB0byBzdXBwb3J0IHdlYiBzZXJ2aWNlcywgc2Vj
dXJpdHk/CkdldCBzdHVmZiBkb25lIHF1aWNrbHkgd2l0aCBwcmUtaW50ZWdyYXRlZCB0ZWNobm9s
b2d5IHRvIG1ha2UgeW91ciBqb2IgZWFzaWVyCkRvd25sb2FkIElCTSBXZWJTcGhlcmUgQXBwbGlj
YXRpb24gU2VydmVyIHYuMS4wLjEgYmFzZWQgb24gQXBhY2hlIEdlcm9uaW1vCmh0dHA6Ly9zZWwu
YXMtdXMuZmFsa2FnLm5ldC9zZWw/Y21kPWxuayZraWQ9MTIwNzA5JmJpZD0yNjMwNTcmZGF0PTEy
MTY0MgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpORlMg
bWFpbGxpc3QgIC0gIE5GU0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKaHR0cHM6Ly9saXN0cy5zb3Vy
Y2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vbmZzCg==

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Sam Falkner]

On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:

> On Saturday, 8. July 2006 05:45, Sam Falkner wrote:
>> On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:
>>> On Monday, 3. July 2006 23:10, Andreas Gruenbacher wrote:
>>>> Hello,
>>>>
>>>> I have been thinking about the problems of interaction between
>>>> NFSv4 ACLs and POSIX, and particularly about the issue of masking
>>>> permissions through chmod and after creating files or directories.
>>>
>>> Here is a follow-up after some personal feedback from Sam. I
>>> believe that draft-ietf-nfsv4-acls-00 is not ready to become part  
>>> of the
>>> NFSv4 Minor Version 1 RFC: some assumptions are not correct from  
>>> a POSIX
>>> point of view, and the way how chmod and file create modes are  
>>> applied to
>>> NFSv4 ACLs is weak and not guaranteed to be correct.
>>
>> I disagree -- see below.
>
> Here are some facts to back my points: Let's assume that a file  
> inherits the
> following ACL when being created (I am using ^(...) here with the  
> meaning of
> "all bitflags except ..."):
>
> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
> 	OWNER@:^(READ_DATA/WRITE_DATA)::DENY
> 	GROUP@:READ_DATA::ALLOW
> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
> 	GROUP@:^READ_DATA::DENY
> 	user@domain:^(READ_DATA/WRITE_DATA)::DENY
> 	EVERYONE@:READ_DATA::ALLOW
>
> This acl is "well structured" in the POSIX sense: OWNER@ will only  
> get the
> owner permissions and none of the other permissions, user@domain  
> and GROUP@
> will only get the permissions intended for them, and only others  
> (neither
> OWNER@ nor user@domain nor GROUP@) will get EVERYONE@ permissions;  
> in other
> words, the acl is even correct for non-monotonic permissions.
>
> According to section 5.1 of draft-ietf-nfsv4-acls [1], the  
> resulting file mode
> permission bits for this acl shall be rw-r--r--.

Your proposal would give this mode: rw-rw-r--.  I think we should  
consider this more carefully.

> After a chmod or a file
> create, alternate file access control mechanisms must be disabled  
> and only
> additional file access control mechanisms may remain active.  
> According to
> POSIX, additional file access control mechanisms require that no  
> user may be
> granted more permissions than the respective file classes permit.  
> In this
> case, user@domain clearly is not in the File Owner Class.  
> (According to
> POSIX, user@domain must be in the File Group Class.) The  
> user@domain user is
> granted WRITE_DATA though, which is *incorrect* from a POSIX point  
> of view.

No, it is not granted WRITE_DATA after a chmod().  After a chmod 644,  
there will be a "user@domain:WRITE_DATA::DENY" prepended.  This is  
well defined in the current minorversion1.  So it is not "incorrect  
from a POSIX point of view."

If your problem is with the computation of the mode, then we can  
discuss this some more.  But following create or chmod, user@domain  
is not granted WRITE_DATA.

> Next, let's assume than an ACL contains the following pair of user- 
> provided
> entries:
>
> 	GROUP@:WRITE_DATA::DENY
> 	GROUP@:READ_DATA::ALLOW
>
> Clearly the user's intention is to deny WRITE_DATA access to GROUP@.

Yes, that *was* the user's intention, at the time the user set the ACL.

> The
> algorithm to apply a mode to an existing ACL will remove the  
> WRITE_DATA bit
> from the GROUP@:WRITE_DATA::DENY entry when a chmod(..., 0770) is done
> though. This is counter to the user's intention, so I would call  
> that *wrong*
> as well.

You would call it wrong that a chmod 770 would allow WRITE_DATA to  
members of the file's owning group?!  The  user did a chmod -- the  
user changed the permissions on the file!

This is not a POSIX flaw, and this is not a design flaw of any kind.   
"chmod 770" grants the owning group permission to write the file,  
period.

> It also violates the principle of least surprise.

Are you kidding?  Consider a directory with this ACE in its ACL:

GROUP@:READ_DATA/WRITE_DATA:FILE_INHERIT:DENY

With your proposal, open("foo", O_CREAT | O_RDWR, 0666) in this  
directory creates a file that the owning group is denied read and  
write permission.  Then:

% chmod 664 foo

Oops, owning group *still* cannot read or write the file!  Linux/*NIX  
has a long history of files having a mode attribute, and users using  
chmod to set permissions -- but not much history with NFSv4 ACLs.   
Your proposal more or less requires that Linux/*NIX users immediately  
start using ACLs, or face the "chmod doesn't fix my file" problem.

I've spent quite some time over the last few days looking for flaws  
in your proposal, but I'll admit that I missed this one, and it's a  
big one.

> There really is no
> safe way to tell user-provided ACL entries from artificially made  
> up ACL
> entries.

The semantics in draft-ietf-nfsv4-acls are well defined, predictable,  
consistent, and reasonable.

> draft-ietf-nfsv4-acls is missing a clear classification of ACL  
> entries into
> the File Owner, File Group, and File Other classes. Every ACL entry  
> must be
> in one of the three classes in order to compute appropriate file mode
> permission bits when setting an ACL, and after inheriting  
> permissions. This
> classification also determines which effect chmod will have on an ACL.

I assume you mean "every ACE", not "every ACL".  As I mentioned  
above, I'm not sure whether or not this is a requirement, but it can  
be discussed further.  However, if it turns out that draft-ietf-nfsv4- 
acls is wrong in this regard, then the only consequence is a minor  
change to 5.1.

> So draft-ietf-nfsv4-acls is *incorrect* and *wrong* from a POSIX  
> point of
> view, while my alternative proposal is correct, apart from being  
> simpler to
> implement. I hope that my emails and some background reading (like  
> the file
> access related parts of the POSIX definitions volume [5], a paper that
> explains POSIX ACLs and how they are implemented on Linux [6], and  
> perhaps
> 1003.1e draft 17) will convince you about that.

I am absolutely not convinced.

This email is getting *way* too long, so I will stop at this point,  
and perhaps will reply to other pieces in the future.

- Sam

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[J. Bruce Fields]

On Mon, Jul 10, 2006 at 07:29:56AM -0600, Sam Falkner wrote:
> On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:
> >According to section 5.1 of draft-ietf-nfsv4-acls [1], the  
> >resulting file mode
> >permission bits for this acl shall be rw-r--r--.
> 
> Your proposal would give this mode: rw-rw-r--.  I think we should  
> consider this more carefully.

As Andreas says, this is what the posix draft would have you do.  It's
also what Linux (and, I assume, Solaris) do in the case of posix ACLs.

If the goals was compatibility with that posix draft, RFC3530 should
have specified that owner, other, and group bits be kept in sync with
(respectively) OWNER@, EVERYONE@, and the *maximum* of permissions given
to any other entity, rather than with OWNER@, EVERYONE@, and GROUP@.

> You would call it wrong that a chmod 770 would allow WRITE_DATA to  
> members of the file's owning group?!  The  user did a chmod -- the  
> user changed the permissions on the file!

That is how posix acl's work; again, the group mode bit really
corresponds to the mask, not to the group acl entry:

	bfields@pickle:~$ getfacl foo
	# file: foo
	# owner: bfields
	# group: bfields
	user::rw-
	user:bfields:r--
	group::r--
	mask::r--
	other::---

	bfields@pickle:~$ chmod 770 foo
	bfields@pickle:~$ getfacl foo
	# file: foo
	# owner: bfields
	# group: bfields
	user::rwx
	user:bfields:r--
	group::r--
	mask::rwx
	other::---


Of course, "posix" acls aren't really posix, and we could do something
else if seems simpler.  Neither behavior seems intuitive to me in all
situations.

--b.


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Sam Falkner]

On Jul 10, 2006, at 8:15 AM, J. Bruce Fields wrote:

> On Mon, Jul 10, 2006 at 07:29:56AM -0600, Sam Falkner wrote:
>> On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:
>>> According to section 5.1 of draft-ietf-nfsv4-acls [1], the
>>> resulting file mode
>>> permission bits for this acl shall be rw-r--r--.
>>
>> Your proposal would give this mode: rw-rw-r--.  I think we should
>> consider this more carefully.
>
> As Andreas says, this is what the posix draft would have you do.  It's
> also what Linux (and, I assume, Solaris) do in the case of posix ACLs.

Not on Solaris.  With POSIX-draft ACLs, adding user:friend:rw- to a  
mode rw-r--r-- file still gives you rw-r--r--.  (And as you point out  
later, these ACLs ain't POSIX.)

> If the goals was compatibility with that posix draft, RFC3530 should
> have specified that owner, other, and group bits be kept in sync with
> (respectively) OWNER@, EVERYONE@, and the *maximum* of permissions  
> given
> to any other entity, rather than with OWNER@, EVERYONE@, and GROUP@.
>
>> You would call it wrong that a chmod 770 would allow WRITE_DATA to
>> members of the file's owning group?!  The  user did a chmod -- the
>> user changed the permissions on the file!
>
> That is how posix acl's work; again, the group mode bit really
> corresponds to the mask, not to the group acl entry:
>
> 	bfields@pickle:~$ getfacl foo
> 	# file: foo
> 	# owner: bfields
> 	# group: bfields
> 	user::rw-
> 	user:bfields:r--
> 	group::r--
> 	mask::r--
> 	other::---
>
> 	bfields@pickle:~$ chmod 770 foo
> 	bfields@pickle:~$ getfacl foo
> 	# file: foo
> 	# owner: bfields
> 	# group: bfields
> 	user::rwx
> 	user:bfields:r--
> 	group::r--
> 	mask::rwx
> 	other::---

Again, not so on Solaris.  I wasn't aware that it was on Linux.  Sigh.

> Of course, "posix" acls aren't really posix, and we could do something
> else if seems simpler.  Neither behavior seems intuitive to me in all
> situations.

I think having chmod be functional, i.e. chmod 770 gives write  
permission to the owning group, and an "ls -l" shows "rwxrwx---",  
would be best by far.

- Sam

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: [NFS] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[J. Bruce Fields]

On Mon, Jul 10, 2006 at 09:32:28AM -0600, Sam Falkner wrote:
> On Jul 10, 2006, at 8:15 AM, J. Bruce Fields wrote:
> > As Andreas says, this is what the posix draft would have you do.  It's
> > also what Linux (and, I assume, Solaris) do in the case of posix ACLs.
> 
> Not on Solaris.  With POSIX-draft ACLs, adding user:friend:rw- to a  
> mode rw-r--r-- file still gives you rw-r--r--.  (And as you point out  
> later, these ACLs ain't POSIX.)
...
> > That is how posix acl's work; again, the group mode bit really
> > corresponds to the mask, not to the group acl entry:
...
> Again, not so on Solaris.  I wasn't aware that it was on Linux.  Sigh.

Ugh, sorry, OK, I didn't understand that we had that difference.

Personally, after seeing how complicated this can get, I almost think
I'd rather translate mode bits to NFSv4 ACLs by translating them to the
obvious ACL with 3 ALLOW ACEs.  And I'd rather translate the mask by
just masking out the bits in the obvious way, rather than adding DENY
aces.

At the very least, I'd rather not *forbid* such an implementation.  Yes,
it makes chmod irreversible, and it's wrong in a few rare corner cases,
but there are advantages to being wrong in a way that's simple and easy
to document.

If we're committed to getting the mask ace right, though, I would prefer
to adopt one of Andreas's solutions; they'd allow us to generate much
simpler ACLs.  I actually prefer the first proposal (letting the server
use the mode bits to mask out permissions).  But if we're going to add
explicit mask aces, then please, let's add only one.  I understand the
theoretical advantage to masking out all three classes, but that's
adding too much complexity for a few corner cases, and I don't think
it's going to be easy for users to understand.

We could add a new ACE type (in addition to ALLOW, DENY, AUDIT, ALARM),
and then a client could query the server's ability to represent the mask
with the aclsupport attribute and decide whether it wants to add DENY's
to represent the mask, or just give up on chmod reversibility.

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

Lisa,

On Saturday, 08 July 2006 08:51, Lisa Week wrote:
> Hi Andreas,
>
> I have a couple additional questions and comments.  See those inline...
>
> [...]
>
> For example, if we have the following ACL:
>      lisa@sun.com:ACE4_WRITE_ACL:deny
>
> 		or even
>
>      lisa@sun.com:ACE4_WRITE_OWNER:allow
>
> Upon chmod we would have to disable them (however an implementation
> chooses to) and effectively remove it.

In my proposal with the owner_class_mask, group_class_mask, and 
other_class_mask attributes, the chmod does not remove any mask bits from the 
ACEs, it sets the mask attributes to reflect the chmod mode parameter. The 
permission check algorithm only considers the effective permissions. So the 
mask attributes define which permissions are enabled and which are disabled.

> The thing that I have a problem with here is the fact that the
> changing of the file permission bits will affect what access has been
> defined in the ACL for things such as ACE4_WRITE_OWNER,
> ACE4_WRITE_ACL, etc.  A user setting the file permission bits is not
> saying anything about what they want to be done with any ACEs that
> include the ACE4_WRITE_OWNER mask bit.  Why would we want to mess
> with them?

It's quite simple: ACE4_WRITE_OWNER is an alternate access control mechanism 
under POSIX, no matter how we look at it. POSIX says that a chmod must disable 
alternate access control mechanisms, and it says that additional access 
control mechanisms may only introduce further restrictions. So a chmod will 
disable ACE4_WRITE_ACL and ACE4_WRITE_OWNER access, in both proposals.

> 2.) So, what if an ACE contained a mixture of the access mask bits
> that are alternate and additional?
>
> Would we allow having ACE4_READ_DATA and ACE4_WRITE_ACL in the same
> ACE?  What would happen to an ACE such as this upon chmod?

Of course we allow such ACEs. In fact, any NFSv4 ACL is allowed(*). Chmod does 
not touch the ACL, it adjusts the mask attributes so that only bits allowed 
by the respective class (File Owner Class, File Group Class, File Other 
Class) will be set in the mask attributes. Because only bits set both in an 
ACE and in the associated mask attribute are effective, all other permissions 
will automatically be disabled. Your proposal achieves the same effect by 
prepending ALLOW entries with DENY entries that deny masked permissions.

(*) See the well-formed ACLs and non-monotonic permissions discussion in the 
previous mails for why we may want to enforce a specific form of ACLs for 
full POSIX compliance, and in which conditions this matters.

> I'll restate it because it is important: EVERYONE@ is not equivalent
> to the File Other Class.  I believe the original intention was to
> have it be equivalent to one the Windows "well known sid":   http://
> msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/
> security/well_known_sid_type.asp

EVERYONE@ in NFSv4 ACLs indeed matches EVERYONE@ in Windows ACLs.

> Really with NFSv4 ACLs, the only way we have the equivalent of a File
> Other Class is if the EVERYONE@ entries come at the end of the ACL.

Again, that's what I discussed as part of well-formed ACLs and non-monotonic 
permissions. Think of it this way:

We classify ACEs as follows:

  - OWNER@ entries and user@domain entries for the user who currently owns
    a file are in the File Owner Class,

  - EVERYONE@ entries are in the File Other Class,

  - all other entries are in the File Group Class.

Well-formed NFSv4 ACLs include DENY entries which make sure that the 
permissions granted to each class (File Owner Class, File Group Class, File 
Other Class) are isolated, and permissions granted to one class will not 
"swap over" to another class. In particular, this means that nobody in the 
File Owner and File Group classes will be granted any permissions from an 
EVERYONE@ ACE.

Arbitrary NFSv4 ACLs are not "well-formed" in this sense. They do not isolate 
the classes, and permissions from several classes may accumulate.

So, for strict POSIX compliance, we much make sure that ACLs are well-formed 
if both is true:

 - they are inherited or chmod'ed

 - and the mask applied to the ACL is non-monotonic

In all other cases (when an ACL is set, or when the permissions are monotonic) 
we will still be within the bounds of POSIX, and so we don't need to care.

So I'll restate that EVERYONE@ entries *are* in the File Other Class. Whether 
or not permissions may "swap over" from one class to another is determined by 
whether or not an ACL is "well-formed". This is an aspect orthogonal to the 
classification, to be dealt with separately. No other classification can fix 
the well-formedness aspect.

> Again, EVERYONE@ is not equivalent to the File Other Class.
> Depending on where an ACE pertaining to EVERYONE@ is in the ACL, it
> could even refer to the owner and the owning group.

Wrong in my opinion: with an ACL that simply consists of a single EVERYONE@ 
ACE, the other permissions will apply to all classes, but that's because the 
ACL is not well-formed, not because EVERYONE@ is classified wrong.

> Sorry, but I don't think I understand.  Andreas, what do you mean by
> "Alternate" permissions in that sentence?

Here is a table of NFSv4 ACL mask bits and their classification. Mask bits are 
classified as Additional if they are either always permitted under POSIX 
(indicated as None in the table), or if they are equivalent to or a subset of 
a POSIX permission (indicated as Read, Write, Execute in the table). Mask 
bits are classified as Alternate if POSIX permissions cannot grant this 
permission (e.g., the equvalent of WRITE_ACL is implicitly granted to the 
owner, but there is no way to grant WRITE_ACL to an arbitrary other user).

READ_DATA               Additional (Read)
LIST_DIRECTORY          Additional (Read)
WRITE_DATA              Additional (Write)
ADD_FILE                Additional (Write)
APPEND_DATA             Additional (Write)
ADD_SUBDIRECTORY        Additional (Write)
READ_NAMED_ATTRS        Additional (Read) (**)
WRITE_NAMED_ATTRS       Additional (Write) (**)
EXECUTE                 Additional (Execute)
DELETE_CHILD            Additional (Write)
READ_ATTRIBUTES         Additional (None)
WRITE_ATTRIBUTES        Alternate
DELETE                  Alternate
READ_ACL                Additional (None)
WRITE_ACL               Alternate
WRITE_OWNER             Alternate
SYNCHRONIZE             Additional (None)

> It is unclear to me as to 
> what happens to the access mask bits outside of the following:
> (collectively, these are the access mask bits that make up the POSIX
> read, write and execute permissions)
> ACE4_READ_DATA, ACE4_READ_ATTRIBUTES, ACE4_READ_ACL, ACE4_SYNCHRONIZE
> ACE4_WRITE_DATA, ACE4_APPEND_DATA, ACE4_WRITE_ATTRIBUTES,
> ACE4_DELETE_CHILD and ACE4_EXECUTE
>
> The remaining ones are:
> ACE4_WRITE_ACL, ACE4_WRITE_OWNER, ACE4_DELETE, ACE4_READ_NAMED_ATTRS
> and ACE4_WRITE_NAMED_ATTRS

(**) I think that Read and Write imply ACE4_READ_NAMED_ATTRS and 
ACE4_WRITE_NAMED_ATTRS on Solaris, respectively, but I'm not sure. In case 
they are not, they would indeed count as Alternate.

> Are these "remaining ones" also given representation in the masks?

Yes. Alternate permissions must be subject to the mask attributes, because we 
must be able to disable them upon chmod and ACL inheritance. We can turn them 
back on later by setting the corresponding bitflags in the mask attributes 
(explicitly, or implicitly by setting a new ACL without also providing mask 
attributes, see further below).

POSIX does not require that alternate file access mechanisms be either on or 
off completely (i.e., an on/off switch); we are free to turn alternate 
permissions on or off individually. (We must turn them all off upon chmod and 
permission inheritance, but that should be clear by now.)

> Actually, I think what is confusing me is that before, when talking
> about Additional and Alternate file access control mechanisms, you
> said that: " All others with ACE4_WRITE_ACL, ACE4_WRITE_OWNER,
> ACE4_DELETE_CHILD, and ACE4_DELETE are alternate."
>
> I just wonder how that statement  relates to the statement that
> "Alternate permissions in the ACL can be enabled by either setting an
> ACL without providing full mask entries, or by setting the
> appropriate bit(s) in the corresponding mask entry or entries."

My proposal was that a SETATTR of ACL that does not also set the mask 
attributes should automatically set all unspecified mask attributes to the 
union of all the ALLOW ACEs in the respective class. In other words, when a 
NFSv4.0 client executes an ACL SETATTR, all the ALLOW permissions in the ACL 
will automatically get set in the respective mask attributes as well, and 
will be effective. POSIX allows this behavior.


Andreas

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Sam Falkner]

On Jul 10, 2006, at 1:57 PM, J. Bruce Fields wrote:

> On Mon, Jul 10, 2006 at 09:32:28AM -0600, Sam Falkner wrote:
>> On Jul 10, 2006, at 8:15 AM, J. Bruce Fields wrote:
>>> As Andreas says, this is what the posix draft would have you do.   
>>> It's
>>> also what Linux (and, I assume, Solaris) do in the case of posix  
>>> ACLs.
>>
>> Not on Solaris.  With POSIX-draft ACLs, adding user:friend:rw- to a
>> mode rw-r--r-- file still gives you rw-r--r--.  (And as you point out
>> later, these ACLs ain't POSIX.)
> ...
>>> That is how posix acl's work; again, the group mode bit really
>>> corresponds to the mask, not to the group acl entry:
> ...
>> Again, not so on Solaris.  I wasn't aware that it was on Linux.   
>> Sigh.
>
> Ugh, sorry, OK, I didn't understand that we had that difference.
>
> Personally, after seeing how complicated this can get, I almost think
> I'd rather translate mode bits to NFSv4 ACLs by translating them to  
> the
> obvious ACL with 3 ALLOW ACEs.  And I'd rather translate the mask by
> just masking out the bits in the obvious way, rather than adding DENY
> aces.
>
> At the very least, I'd rather not *forbid* such an implementation.   
> Yes,
> it makes chmod irreversible, and it's wrong in a few rare corner  
> cases,
> but there are advantages to being wrong in a way that's simple and  
> easy
> to document.
>
> If we're committed to getting the mask ace right, though, I would  
> prefer
> to adopt one of Andreas's solutions; they'd allow us to generate much
> simpler ACLs.  I actually prefer the first proposal (letting the  
> server
> use the mode bits to mask out permissions).  But if we're going to add
> explicit mask aces, then please, let's add only one.  I understand the
> theoretical advantage to masking out all three classes, but that's
> adding too much complexity for a few corner cases, and I don't think
> it's going to be easy for users to understand.

How would a scheme that uses one and only one mask ACE work?  Are you  
thinking of catching mode 077 via a

OWNER@:READ_DATA/WRITE_DATA/EXECUTE:DENY

but having no way to catch mode 707 (because GROUP@:READ_DATA/ 
WRITE_DATA/EXECUTE:DENY might catch the owner)?

> We could add a new ACE type (in addition to ALLOW, DENY, AUDIT,  
> ALARM),
> and then a client could query the server's ability to represent the  
> mask
> with the aclsupport attribute and decide whether it wants to add  
> DENY's
> to represent the mask, or just give up on chmod reversibility.

Please explain this further.  What would the fifth ACE type do?  What  
would it give you that DENY wouldn't?

- Sam


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[J. Bruce Fields]

On Mon, Jul 10, 2006 at 05:26:32PM -0500, Sam Falkner wrote:
> 
> On Jul 10, 2006, at 1:57 PM, J. Bruce Fields wrote:
> >If we're committed to getting the mask ace right, though, I would
> >prefer to adopt one of Andreas's solutions; they'd allow us to
> >generate much simpler ACLs.  I actually prefer the first proposal
> >(letting the  server use the mode bits to mask out permissions).  But
> >if we're going to add explicit mask aces, then please, let's add only
> >one.  I understand the theoretical advantage to masking out all three
> >classes, but that's adding too much complexity for a few corner
> >cases, and I don't think it's going to be easy for users to
> >understand.
> 
> How would a scheme that uses one and only one mask ACE work?  Are you
> thinking of catching mode 077 via a
> 
> OWNER@:READ_DATA/WRITE_DATA/EXECUTE:DENY
> 
> but having no way to catch mode 707 (because GROUP@:READ_DATA/
> WRITE_DATA/EXECUTE:DENY might catch the owner)?

Andreas's proposal was actually to add something new to the protocol
(either a new attribute, or a new special entity (like "MASK@")) to
transfer the mask.  One of the advantages of doing that is that you'd no
longer have to use a bunch of DENY ACEs scattered through the ACL, all
carrying the same information.  E.g. you'd the client to include an ACE
like

	MASK@:READ_DATA:DENY

and modify the NFSv4 acl-permission-checking algorithm to mask out any
bitmasks anywhere other than OWNER@ or DENY@.

But Andreas was proposing that we actually add 3 different types of
masks, one for the OWNER@, one for EVERYONE@, and one for the others,
and I think that's overkill.  So that's what I'm arguing against.

> >We could add a new ACE type (in addition to ALLOW, DENY, AUDIT,
> >ALARM), and then a client could query the server's ability to
> >represent the  mask with the aclsupport attribute and decide whether
> >it wants to add  DENY's to represent the mask, or just give up on
> >chmod reversibility.
> 
> Please explain this further.  What would the fifth ACE type do?  What
> would it give you that DENY wouldn't?

It's just a way to pass the mask inside the ACL, but using a new ACE
type instead of a new special entity.

The advantage is that a client can actually probe to see if the server
supports it, so we wouldn't have to make it mandatory for a server to
support it.  But a separate attribute would also have that property.

--b.


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[J. Bruce Fields]

On Mon, Jul 10, 2006 at 06:39:39PM -0400, J. Bruce Fields wrote:
> and modify the NFSv4 acl-permission-checking algorithm to mask out any
> bitmasks anywhere other than OWNER@ or DENY@.

(Err, I meant to say "OWNER@ or EVERYONE@", sorry....)

--b.


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

On Monday, 10. July 2006 15:29, Sam Falkner wrote:
> On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:
> > On Saturday, 8. July 2006 05:45, Sam Falkner wrote:
> >> On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:
> >>> On Monday, 3. July 2006 23:10, Andreas Gruenbacher wrote:
> >>>> Hello,
> >>>>
> >>>> I have been thinking about the problems of interaction between
> >>>> NFSv4 ACLs and POSIX, and particularly about the issue of masking
> >>>> permissions through chmod and after creating files or directories.
> >>>
> >>> Here is a follow-up after some personal feedback from Sam. I
> >>> believe that draft-ietf-nfsv4-acls-00 is not ready to become part
> >>> of the
> >>> NFSv4 Minor Version 1 RFC: some assumptions are not correct from
> >>> a POSIX
> >>> point of view, and the way how chmod and file create modes are
> >>> applied to
> >>> NFSv4 ACLs is weak and not guaranteed to be correct.
> >>
> >> I disagree -- see below.
> >
> > Here are some facts to back my points: Let's assume that a file
> > inherits the
> > following ACL when being created (I am using ^(...) here with the
> > meaning of
> > "all bitflags except ..."):
> >
> > 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
> > 	OWNER@:^(READ_DATA/WRITE_DATA)::DENY
> > 	GROUP@:READ_DATA::ALLOW
> > 	user@domain:READ_DATA/WRITE_DATA::ALLOW
> > 	GROUP@:^READ_DATA::DENY
> > 	user@domain:^(READ_DATA/WRITE_DATA)::DENY
> > 	EVERYONE@:READ_DATA::ALLOW
> >
> > This acl is "well structured" in the POSIX sense: OWNER@ will only
> > get the
> > owner permissions and none of the other permissions, user@domain
> > and GROUP@
> > will only get the permissions intended for them, and only others
> > (neither
> > OWNER@ nor user@domain nor GROUP@) will get EVERYONE@ permissions;
> > in other
> > words, the acl is even correct for non-monotonic permissions.
> >
> > According to section 5.1 of draft-ietf-nfsv4-acls [1], the
> > resulting file mode
> > permission bits for this acl shall be rw-r--r--.
>
> Your proposal would give this mode: rw-rw-r--.  I think we should
> consider this more carefully.
>
> > After a chmod or a file
> > create, alternate file access control mechanisms must be disabled
> > and only
> > additional file access control mechanisms may remain active.
> > According to
> > POSIX, additional file access control mechanisms require that no
> > user may be
> > granted more permissions than the respective file classes permit.
> > In this
> > case, user@domain clearly is not in the File Owner Class.
> > (According to
> > POSIX, user@domain must be in the File Group Class.) The
> > user@domain user is
> > granted WRITE_DATA though, which is *incorrect* from a POSIX point
> > of view.
>
> No, it is not granted WRITE_DATA after a chmod().  After a chmod 644,
> there will be a "user@domain:WRITE_DATA::DENY" prepended.  This is
> well defined in the current minorversion1.  So it is not "incorrect
> from a POSIX point of view."

Now that I look at the example again, I realize that I didn't define the 
create mode. With create mode 640 or less permissive, everything is fine. 
Let's assume create mode 664 though: then the file mode permission bits will 
still come out as rw-r--r--, but the ACL will grant WRITE_DATA to 
user@domain. That's the case I meant, and this case is not POSIX compliant.

> If your problem is with the computation of the mode, then we can
> discuss this some more.  But following create or chmod, user@domain
> is not granted WRITE_DATA.

My problems are these:

* the algorithm in 5.3 is based on an ACE classification closer to the one
  I proposed, while the algorithm in 5.1 is based on a different
  classsification. We need to straighten this out, and I have argued
  repeatedly now why the classification I proposed leads to consistent
  and correct results. Most of the little inconsistencies in
  draft-ietf-nfsv4-acls-00 will stick out quite clearly once we agree on
  the right classification, and they will be easy to fix.

* the DENY entries introduced to mask permissions bloat the ACL, and make
  the ACL look strange to non-POSIX systems. The algorithm in section 5.3
  may remove permissions from user-provided DENY entries in some cases,
  and it may introduce duplicate DENY entries in some situations such as
  when another system reorders ACEs.Some versions of Windows do that.

The alternative approach I am proposing has a clear classification of ACEs, 
separates the orthogonal aspects of classification vs. well-formed acls, and 
has none of the weaknesses that the mask DENY ACEs cause.

> > Next, let's assume than an ACL contains the following pair of user-
> > provided entries:
> >
> > 	GROUP@:WRITE_DATA::DENY
> > 	GROUP@:READ_DATA::ALLOW
> >
> > Clearly the user's intention is to deny WRITE_DATA access to GROUP@.
>
> Yes, that *was* the user's intention, at the time the user set the ACL.

Hm... not the best example because GROUP@ is the owning group, which 
corresponds to the group file mode permission bits in traditional POSIX. The 
problem is more difficult to see in this case, but I argue that the owhning 
group permissions and the group file mode permission bits are not the same
with ACLs: the file group mode permission bits restrict GROUP@ entries, and 
all user@domain and group@domain entries in the acl. For the sake of this 
example, substitute GROUP@ with user@domain though, and you'll see the 
problem more clearly: a user adds an explicit user@domain:WRITE_DATA::DENY 
entry to an acl which is followed by a user@domain:READ_DATA::ALLOW entry. 
After a chmod to 664 for example, this user suddenly has write access. The 
user clearly did not intend this to happen.

> > The algorithm to apply a mode to an existing ACL will remove the
> > WRITE_DATA bit
> > from the GROUP@:WRITE_DATA::DENY entry when a chmod(..., 0770) is done
> > though. This is counter to the user's intention, so I would call
> > that *wrong*
> > as well.
>
> You would call it wrong that a chmod 770 would allow WRITE_DATA to
> members of the file's owning group?!  The  user did a chmod -- the
> user changed the permissions on the file!

Yes. The user set the group file mode permission bits to rwx, in other words, 
ACEs in the File Group Class are limited to rwx after that. This does not 
imply that GROUP@ ACEs automatically have the equivalent of rwx though: the 
File Group Class contains several ACL entries, and you want to control the 
group file mode permission bits independently from the permissions of the 
owning group: otherwise, it wouldn't be possible to give the owning group 
fewer permissions than any user@domain or group@domain entry.

Let's look at this ACL:

	OWNER@:READ_DATA/WRITE_DATA::ALLOW
	GROUP@:READ_DATA::ALLOW
	user@domain:READ_DATA/WRITE_DATA::ALLOW
	EVERYONE@:READ_DATE::ALLOW

The GROUP@ and user@domain entries are in the File Group Class. After a chmod 
to 664, the ACL changes to this in Sam's proposal (some unnecessary 
permissions left out):

	OWNER@:EXECUTE::DENY
	OWNER@:READ_DATA/WRITE_DATA::ALLOW
	GROUP@:EXECUTE::DENY
	GROUP@:READ_DATA::ALLOW
	user@domain:EXECUTE::DENY
	user@domain:READ_DATA/WRITE_DATA::ALLOW
	EVERYONE@:WRITE_DATA/EXECUTE::DENY
	EVERYONE@:READ_DATE::ALLOW

In my proposal, the ACL would remain the same as before the chmod, but the 
owner_class_mask would become READ_DATA/WRITE_DATA, the group_class_mask 
would become READ_DATA/WRITE_DATA, and the other_class_mask would become 
READ_DATA. Note that the ACL does *not* grant write access to GROUP@ in 
either case.

> This is not a POSIX flaw, and this is not a design flaw of any kind.
> "chmod 770" grants the owning group permission to write the file,
> period.

No, see above. chmod 770 grants the File Group Class rwx, but ACLs act as an 
additional file access control mechanism here, and further limit the 
permissions granted to the owning group, which is a member of the File Group 
Class.

> > It also violates the principle of least surprise.
>
> Are you kidding?

I did not mean to.

> Consider a directory with this ACE in its ACL: 
> GROUP@:READ_DATA/WRITE_DATA:FILE_INHERIT:DENY
>
> With your proposal, open("foo", O_CREAT | O_RDWR, 0666) in this
> directory creates a file that the owning group is denied read and
> write permission.  Then:
>
> % chmod 664 foo
>
> Oops, owning group *still* cannot read or write the file!  Linux/*NIX
> has a long history of files having a mode attribute, and users using
> chmod to set permissions -- but not much history with NFSv4 ACLs.

To counter that argument, UNIX systems, including and foremost Solaris, but 
also others like Linux, have had POSIX ACLs for quite some time, and there 
the same "chmod doesn't fix my file" case exists, and it hasn't been a 
problem at all.

The GROUP@:READ_DATA/WRITE_DATA:FILE_INHERIT:DENY ace is a clear case of 
"doctor it hurts when I do this". As is an EVERYONE@:*::DENY ACL entry.

> Your proposal more or less requires that Linux/*NIX users immediately
> start using ACLs, or face the "chmod doesn't fix my file" problem.

Chmod by definition *cannot* fix all permission problems in the presence of 
ACLs unless it completely replaces the ACL with something like the six-entry 
acl pattern in draft-ietf-nfsv4-acls-00. We already know that it's not a good 
idea to have chmod destroy acls.

> I've spent quite some time over the last few days looking for flaws
> in your proposal, but I'll admit that I missed this one, and it's a
> big one.

May I ask you to come back to this issue in case you still feel the same way 
after this reply?

> > There really is no safe way to tell user-provided ACL entries from
> > artificially made up ACL entries.
>
> The semantics in draft-ietf-nfsv4-acls are well defined, predictable,
> consistent, and reasonable.

"Well defined": for one thing, draft-ietf-nfsv4-acls-00 is not explicit or 
clear about the ACE classification it is based on.

"Predictable": probably yes.

"Consistent": it uses different classifications in sections 5.1 and 5.3. 

"Reasonable": I don't like the DENY ACEs at all but that's a matter of taste. 
The problems which the DENY ACEs cause are no matter of taste though, and I 
would call the design unreasonable for that reason. Enforcing the DENY ACEs 
on thers when an alternative design exists that avoids the known problems 
that they have does not seem very reasonable to me, either.

The two proposals have two fundamental differences:

* My proposal tries to be clear in semantics, and separates orthogonal
  aspects from each other. draft-ietf-nfsv4-acls-00 has a number of
  weaknesses when it comes to clarity of semantics. I am positive that
  we will manage to clarify all these areas in draft-ietf-nfsv4-acls-00.
  At that point, the *only* essential difference that will remain between
  the two proposals will be that

* draft-ietf-nfsv4-acls-00 uses DENY ACL entries for masking permissions,
  while my proposal uses explicit mask attributes.

> > draft-ietf-nfsv4-acls is missing a clear classification of ACL
> > entries into the File Owner, File Group, and File Other classes. Every
> > ACL entry must be in one of the three classes in order to compute
> > appropriate file mode permission bits when setting an ACL, and after
> > inheriting permissions. This classification also determines which effect
> > chmod will have on an ACL. 
>
> I assume you mean "every ACE", not "every ACL".

	every ACL entry == every ACE

> As I mentioned above, I'm not sure whether or not this is a requirement,
> but it can be discussed further.

How else can a chmod 700 disable all but the owner permissions, a chmod 770 
disable all "others" to have access, and a chmod 000 disable all permissions 
if you don't know which ACEs each class applies to?

> However, if it turns out that draft-ietf-nfsv4-acls is wrong in this regard,
> then the only consequence is a minor change to 5.1.

I hope I can also convince you that the DENY entries to mask permissions are a 
really bad idea.

> > So draft-ietf-nfsv4-acls is *incorrect* and *wrong* from a POSIX
> > point of
> > view, while my alternative proposal is correct, apart from being
> > simpler to
> > implement. I hope that my emails and some background reading (like
> > the file
> > access related parts of the POSIX definitions volume [5], a paper that
> > explains POSIX ACLs and how they are implemented on Linux [6], and
> > perhaps
> > 1003.1e draft 17) will convince you about that.
>
> I am absolutely not convinced.

I would still recommend that you read [6] at least.

Andreas

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

On Monday, 10. July 2006 16:15, J. Bruce Fields wrote:
> On Mon, Jul 10, 2006 at 07:29:56AM -0600, Sam Falkner wrote:
> > On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:
> > >According to section 5.1 of draft-ietf-nfsv4-acls [1], the
> > >resulting file mode
> > >permission bits for this acl shall be rw-r--r--.
> >
> > Your proposal would give this mode: rw-rw-r--.  I think we should
> > consider this more carefully.
>
> As Andreas says, this is what the posix draft would have you do.  It's
> also what Linux (and, I assume, Solaris) do in the case of posix ACLs.

We are not talking about the POSIX 1003.1e draft here, we are talking about 
the real POSIX standard.

> If the goals was compatibility with that posix draft, RFC3530 should
> have specified that owner, other, and group bits be kept in sync with
> (respectively) OWNER@, EVERYONE@, and the *maximum* of permissions given
> to any other entity, rather than with OWNER@, EVERYONE@, and GROUP@.

I argued why I think this is a misbelief, please scan for well-formed ACLs and 
non-monotonic permissions.

> > You would call it wrong that a chmod 770 would allow WRITE_DATA to
> > members of the file's owning group?!  The  user did a chmod -- the
> > user changed the permissions on the file!
>
> That is how posix acl's work; again, the group mode bit really
> corresponds to the mask, not to the group acl entry:
>
> 	bfields@pickle:~$ getfacl foo
> 	# file: foo
> 	# owner: bfields
> 	# group: bfields
> 	user::rw-
> 	user:bfields:r--
> 	group::r--
> 	mask::r--
> 	other::---
>
> 	bfields@pickle:~$ chmod 770 foo
> 	bfields@pickle:~$ getfacl foo
> 	# file: foo
> 	# owner: bfields
> 	# group: bfields
> 	user::rwx
> 	user:bfields:r--
> 	group::r--
> 	mask::rwx
> 	other::---
>
>
> Of course, "posix" acls aren't really posix, and we could do something
> else if seems simpler.  Neither behavior seems intuitive to me in all
> situations.

The issue is that you sometimes want to give the owning group fewer perissions 
than say, user:bfields in the above example. You can only do that by 
separating the owning group and mask permissions.

For this aspect of the problem (actually for all aspects except for those that 
the DENY entries cause because they are sometimes difficult or impossible to 
uniquely tell from other "ordinary" entries) it is totally irrelevant whether 
the mask is represented as a mask:: acl entry as in POSIX ACLs, as a series 
of DENY ACL entries, or as NFSv4 attributes.

(POSIX ACLs only need one mask entry because they can never grant more than 
rwx permissions anyway, and so the owner and other permissions are always 
identical to the owner and other file mode permission bits. That's no longer 
true with POSIX ACLs, and so there we also need mask entries for the owner 
and for others.)

Andreas

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

On Monday, 10. July 2006 17:32, Sam Falkner wrote:
> On Jul 10, 2006, at 8:15 AM, J. Bruce Fields wrote:
> > On Mon, Jul 10, 2006 at 07:29:56AM -0600, Sam Falkner wrote:
> >> On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:
> >>> According to section 5.1 of draft-ietf-nfsv4-acls [1], the
> >>> resulting file mode
> >>> permission bits for this acl shall be rw-r--r--.
> >>
> >> Your proposal would give this mode: rw-rw-r--.  I think we should
> >> consider this more carefully.
> >
> > As Andreas says, this is what the posix draft would have you do.  It's
> > also what Linux (and, I assume, Solaris) do in the case of posix ACLs.
>
> Not on Solaris.  With POSIX-draft ACLs, adding user:friend:rw- to a
> mode rw-r--r-- file still gives you rw-r--r--.  (And as you point out
> later, these ACLs ain't POSIX.)

Indeed, they are only pretty close. One other difference is that Solaris POSIX 
ACLs are always four-entry on some (all?) file systems, while Draft 17 ACLs 
as implemented on Irix, FreeBSD, Linux, and possibly others support 
three-entry ACLs as well (they are equivalent to the file mode permission 
bits.)

It would be bad to repeat the mistake of breaking POSIX assumptions.

> I think having chmod be functional, i.e. chmod 770 gives write
> permission to the owning group, and an "ls -l" shows "rwxrwx---",
> would be best by far.

It screws you when you want to give the owning group fewer permissions than 
other users in the File Group Class. This can be worked around by creating a 
dummy group with no members, or one group that only contains a single user 
for each user, and changing the owning group of files, but the owning group 
already has other defined uses in POSIX (think of SETGID for files and 
directories), and so it's not desirable and not always possible to change the 
owning group to such a dummy group.

Andreas

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[J. Bruce Fields]

On Tue, Jul 11, 2006 at 02:01:42AM +0200, Andreas Gruenbacher wrote:
> The issue is that you sometimes want to give the owning group fewer perissions 
> than say, user:bfields in the above example. You can only do that by 
> separating the owning group and mask permissions.
> 
> For this aspect of the problem (actually for all aspects except for those that 
> the DENY entries cause because they are sometimes difficult or impossible to 
> uniquely tell from other "ordinary" entries) it is totally irrelevant whether 
> the mask is represented as a mask:: acl entry as in POSIX ACLs, as a series 
> of DENY ACL entries, or as NFSv4 attributes.
> 
> (POSIX ACLs only need one mask entry because they can never grant more than 
> rwx permissions anyway, and so the owner and other permissions are always 
> identical to the owner and other file mode permission bits. That's no longer 
> true with POSIX ACLs, and so there we also need mask entries for the owner 
> and for others.)

So you need this if and only if you want to be able to set OWNER@
permissions other than read, write, or execute, *and* want to be able to
recover from a chmod?

The argument for the reversibility of chmod seems a lot stronger when
the information that could be lost is a long list of users and
permissions than when it's just a few bits for the owner.

--b.


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

On Tuesday, 11. July 2006 00:39, J. Bruce Fields wrote:
> On Mon, Jul 10, 2006 at 05:26:32PM -0500, Sam Falkner wrote:
> > On Jul 10, 2006, at 1:57 PM, J. Bruce Fields wrote:
> > >If we're committed to getting the mask ace right, though, I would
> > >prefer to adopt one of Andreas's solutions; they'd allow us to
> > >generate much simpler ACLs.  I actually prefer the first proposal
> > >(letting the  server use the mode bits to mask out permissions).  But
> > >if we're going to add explicit mask aces, then please, let's add only
> > >one.  I understand the theoretical advantage to masking out all three
> > >classes, but that's adding too much complexity for a few corner
> > >cases, and I don't think it's going to be easy for users to
> > >understand.
> >
> > How would a scheme that uses one and only one mask ACE work?  Are you
> > thinking of catching mode 077 via a
> >
> > OWNER@:READ_DATA/WRITE_DATA/EXECUTE:DENY
> >
> > but having no way to catch mode 707 (because GROUP@:READ_DATA/
> > WRITE_DATA/EXECUTE:DENY might catch the owner)?
>
> Andreas's proposal was actually to add something new to the protocol
> (either a new attribute, or a new special entity (like "MASK@")) to
> transfer the mask.  One of the advantages of doing that is that you'd no
> longer have to use a bunch of DENY ACEs scattered through the ACL, all
> carrying the same information.  E.g. you'd the client to include an ACE
> like
>
> 	MASK@:READ_DATA:DENY
>
> and modify the NFSv4 acl-permission-checking algorithm to mask out any
> bitmasks anywhere other than OWNER@ or DENY@.

Another benefit would be that we can tell what are MASK entries and which 
entries are not. That's not always possible with the DENY entries.

> But Andreas was proposing that we actually add 3 different types of
> masks, one for the OWNER@, one for EVERYONE@, and one for the others,
> and I think that's overkill.  So that's what I'm arguing against.

The reason for adding owner and other masks was this: we want to be able to 
turn off alternate permissions upon chmod and acl inheritance. We can already 
easily do that for the File Group Class by cleaning the alternate mask bits 
there; it's the same mechanism we also use for turning off additional mask 
bits for chmod, for example. We need to be able to turn off alternate and 
additional mode bits for the owner and for others as well in cases like 
chmod. Now we could devise a different mechanism for turning off alternate 
permissions for the owner and for others (like a bit somewhere), but that 
would still leave us with the problem of how to turn off additional mask 
bits. The NFSv4 ACL mask bits are more fine-grained that the POSIX mask bits, 
and we don't want to destroy the granularity of the NFSv4 ACL mask bits when 
masking permissions. Therefore, we need mask entries for the owner and for 
others as well.

Consider this ACL:

	OWNER@:READ_DATA/WRITE_DATA::ALLOW
	GROUP@:APPEND_DATA::DENY
	GROUP@:READ_DATA::ALLOW
	EVERYONE@:APPEND_DATA::ALLOW

The corresponding mode is 0642 (rw-r---w-). POSIX applications will know 
nothing about the fact that others are only allowed to append data to that 
file. Now consider that a user does a chmod(file, 0) followed by a 
chmod(file, 0642). Which permissions should others have after the chmod? Not 
full write access I assume; POSIX applications should not remove restrictions 
they are not even aware of by accident.

Using the same masking mechanism across all three classes and being able to 
selectively turn alternate mask bits on and off for all classes can only be a 
benefit.

> > >We could add a new ACE type (in addition to ALLOW, DENY, AUDIT,
> > >ALARM), and then a client could query the server's ability to
> > >represent the  mask with the aclsupport attribute and decide whether
> > >it wants to add  DENY's to represent the mask, or just give up on
> > >chmod reversibility.
> >
> > Please explain this further.  What would the fifth ACE type do?  What
> > would it give you that DENY wouldn't?
>
> It's just a way to pass the mask inside the ACL, but using a new ACE
> type instead of a new special entity.

Yes, that was one of the possible designs.

> The advantage is that a client can actually probe to see if the server
> supports it, so we wouldn't have to make it mandatory for a server to
> support it.  But a separate attribute would also have that property.

Advantages of attributes are that clients will never be bothered with ACE 
types they don't know. We can directly access attibutes, rather than scanning 
for the right ACEs, inserting ACEs in case they are missing, etc. There will 
be exactly three masks (or so I hope), and I don't see why we should need to 
add more classes later. We can store all three classes as a single attribute 
though; that may be more acceptable that three separate attributes.

Andreas

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

On Tuesday, 11. July 2006 02:28, J. Bruce Fields wrote:
> On Tue, Jul 11, 2006 at 02:01:42AM +0200, Andreas Gruenbacher wrote:
> > The issue is that you sometimes want to give the owning group fewer
> > perissions than say, user:bfields in the above example. You can only do
> > that by separating the owning group and mask permissions.
> >
> > For this aspect of the problem (actually for all aspects except for those
> > that the DENY entries cause because they are sometimes difficult or
> > impossible to uniquely tell from other "ordinary" entries) it is totally
> > irrelevant whether the mask is represented as a mask:: acl entry as in
> > POSIX ACLs, as a series of DENY ACL entries, or as NFSv4 attributes.
> >
> > (POSIX ACLs only need one mask entry because they can never grant more
> > than rwx permissions anyway, and so the owner and other permissions are
> > always identical to the owner and other file mode permission bits. That's
> > no longer true with POSIX ACLs, and so there we also need mask entries
> > for the owner and for others.)
>
> So you need this if and only if you want to be able to set OWNER@
> permissions other than read, write, or execute, *and* want to be able to
> recover from a chmod?

I think I have answered this exhaustively in:

Subject: Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask,
         draft-ietf-nfsv4-acls-00 not ready
Date: Tue, 11 Jul 2006 02:44:30 +0200
Message-Id: <200607110244.31010.agruen@suse.de>

Andreas

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Sam Falkner]

On Jul 10, 2006, at 7:15 PM, Andreas Gruenbacher wrote:

> On Monday, 10. July 2006 17:32, Sam Falkner wrote:
>> On Jul 10, 2006, at 8:15 AM, J. Bruce Fields wrote:
>>> On Mon, Jul 10, 2006 at 07:29:56AM -0600, Sam Falkner wrote:
>>>> On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:
>>>>> According to section 5.1 of draft-ietf-nfsv4-acls [1], the
>>>>> resulting file mode
>>>>> permission bits for this acl shall be rw-r--r--.
>>>>
>>>> Your proposal would give this mode: rw-rw-r--.  I think we should
>>>> consider this more carefully.
>>>
>>> As Andreas says, this is what the posix draft would have you do.   
>>> It's
>>> also what Linux (and, I assume, Solaris) do in the case of posix  
>>> ACLs.
>>
>> Not on Solaris.  With POSIX-draft ACLs, adding user:friend:rw- to a
>> mode rw-r--r-- file still gives you rw-r--r--.  (And as you point out
>> later, these ACLs ain't POSIX.)
>
> Indeed, they are only pretty close. One other difference is that  
> Solaris POSIX
> ACLs are always four-entry on some (all?) file systems, while Draft  
> 17 ACLs
> as implemented on Irix, FreeBSD, Linux, and possibly others support
> three-entry ACLs as well (they are equivalent to the file mode  
> permission
> bits.)
>
> It would be bad to repeat the mistake of breaking POSIX assumptions.
>
>> I think having chmod be functional, i.e. chmod 770 gives write
>> permission to the owning group, and an "ls -l" shows "rwxrwx---",
>> would be best by far.
>
> It screws you when you want to give the owning group fewer  
> permissions than
> other users in the File Group Class. This can be worked around by  
> creating a
> dummy group with no members, or one group that only contains a  
> single user
> for each user, and changing the owning group of files, but the  
> owning group
> already has other defined uses in POSIX (think of SETGID for files and
> directories), and so it's not desirable and not always possible to  
> change the
> owning group to such a dummy group.

No -- if you want owning group to have fewer permissions than other  
users, you're using an ACL.  You use tools that manipulate ACLs.

Solaris' POSIX-draft ACLs have the property that chmod works (i.e.  
you can set group permissions), and you use setfacl if you want to  
change other entries.  It's perfectly easy to have owning group have  
fewer permissions than supplimental users.

The bottom line is that chmod must set the mode, rather than "set the  
mode, unless there's some sort of ACL thingy, in which case the group  
bits aren't the group bits but are instead the mask bits".

- Sam


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Sam Falkner]

On Jul 10, 2006, at 5:50 PM, Andreas Gruenbacher wrote:

> On Monday, 10. July 2006 15:29, Sam Falkner wrote:
>> On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:
>>> On Saturday, 8. July 2006 05:45, Sam Falkner wrote:
>>>> On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:
>>>>> On Monday, 3. July 2006 23:10, Andreas Gruenbacher wrote:

>>> Here are some facts to back my points: Let's assume that a file
>>> inherits the
>>> following ACL when being created (I am using ^(...) here with the
>>> meaning of
>>> "all bitflags except ..."):
>>>
>>> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
>>> 	OWNER@:^(READ_DATA/WRITE_DATA)::DENY
>>> 	GROUP@:READ_DATA::ALLOW
>>> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
>>> 	GROUP@:^READ_DATA::DENY
>>> 	user@domain:^(READ_DATA/WRITE_DATA)::DENY
>>> 	EVERYONE@:READ_DATA::ALLOW
>>>
>>> This acl is "well structured" in the POSIX sense: OWNER@ will only
>>> get the
>>> owner permissions and none of the other permissions, user@domain
>>> and GROUP@
>>> will only get the permissions intended for them, and only others
>>> (neither
>>> OWNER@ nor user@domain nor GROUP@) will get EVERYONE@ permissions;
>>> in other
>>> words, the acl is even correct for non-monotonic permissions.
>>>
>>> According to section 5.1 of draft-ietf-nfsv4-acls [1], the
>>> resulting file mode
>>> permission bits for this acl shall be rw-r--r--.
>>
>> Your proposal would give this mode: rw-rw-r--.  I think we should
>> consider this more carefully.
>>
>>> After a chmod or a file
>>> create, alternate file access control mechanisms must be disabled
>>> and only
>>> additional file access control mechanisms may remain active.
>>> According to
>>> POSIX, additional file access control mechanisms require that no
>>> user may be
>>> granted more permissions than the respective file classes permit.
>>> In this
>>> case, user@domain clearly is not in the File Owner Class.
>>> (According to
>>> POSIX, user@domain must be in the File Group Class.) The
>>> user@domain user is
>>> granted WRITE_DATA though, which is *incorrect* from a POSIX point
>>> of view.
>>
>> No, it is not granted WRITE_DATA after a chmod().  After a chmod 644,
>> there will be a "user@domain:WRITE_DATA::DENY" prepended.  This is
>> well defined in the current minorversion1.  So it is not "incorrect
>> from a POSIX point of view."
>
> Now that I look at the example again, I realize that I didn't  
> define the
> create mode. With create mode 640 or less permissive, everything is  
> fine.
> Let's assume create mode 664 though: then the file mode permission  
> bits will
> still come out as rw-r--r--, but the ACL will grant WRITE_DATA to
> user@domain. That's the case I meant, and this case is not POSIX  
> compliant.

Wrong.  The file mode permission bits will be rw-rw-r--.  There is no  
problem with POSIX compliance.

>> If your problem is with the computation of the mode, then we can
>> discuss this some more.  But following create or chmod, user@domain
>> is not granted WRITE_DATA.
>
> My problems are these:
>
> * the algorithm in 5.3 is based on an ACE classification closer to  
> the one
>   I proposed, while the algorithm in 5.1 is based on a different
>   classsification. We need to straighten this out, and I have argued
>   repeatedly now why the classification I proposed leads to consistent
>   and correct results. Most of the little inconsistencies in
>   draft-ietf-nfsv4-acls-00 will stick out quite clearly once we  
> agree on
>   the right classification, and they will be easy to fix.
>
> * the DENY entries introduced to mask permissions bloat the ACL,  
> and make
>   the ACL look strange to non-POSIX systems. The algorithm in  
> section 5.3
>   may remove permissions from user-provided DENY entries in some  
> cases,
>   and it may introduce duplicate DENY entries in some situations  
> such as
>   when another system reorders ACEs.Some versions of Windows do that.
>
> The alternative approach I am proposing has a clear classification  
> of ACEs,
> separates the orthogonal aspects of classification vs. well-formed  
> acls, and
> has none of the weaknesses that the mask DENY ACEs cause.
>
>>> Next, let's assume than an ACL contains the following pair of user-
>>> provided entries:
>>>
>>> 	GROUP@:WRITE_DATA::DENY
>>> 	GROUP@:READ_DATA::ALLOW
>>>
>>> Clearly the user's intention is to deny WRITE_DATA access to GROUP@.
>>
>> Yes, that *was* the user's intention, at the time the user set the  
>> ACL.
>
> Hm... not the best example because GROUP@ is the owning group, which
> corresponds to the group file mode permission bits in traditional  
> POSIX. The
> problem is more difficult to see in this case, but I argue that the  
> owhning
> group permissions and the group file mode permission bits are not  
> the same
> with ACLs: the file group mode permission bits restrict GROUP@  
> entries, and
> all user@domain and group@domain entries in the acl. For the sake  
> of this
> example, substitute GROUP@ with user@domain though, and you'll see the
> problem more clearly: a user adds an explicit  
> user@domain:WRITE_DATA::DENY
> entry to an acl which is followed by a user@domain:READ_DATA::ALLOW  
> entry.
> After a chmod to 664 for example, this user suddenly has write  
> access. The
> user clearly did not intend this to happen.

No -- after the chmod, the DENY still stands, unaltered.

- Sam


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Lisa Week]

[-- Attachment #1.1: Type: text/plain, Size: 16564 bytes --]


On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:

> On Saturday, 8. July 2006 05:45, Sam Falkner wrote:
>> On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:
>>> On Monday, 3. July 2006 23:10, Andreas Gruenbacher wrote:
>>>> Hello,
>>>>
>>>> I have been thinking about the problems of interaction between
>>>> NFSv4 ACLs and POSIX, and particularly about the issue of masking
>>>> permissions through chmod and after creating files or directories.
>>>
>>> Here is a follow-up after some personal feedback from Sam. I
>>> believe that draft-ietf-nfsv4-acls-00 is not ready to become part  
>>> of the
>>> NFSv4 Minor Version 1 RFC: some assumptions are not correct from  
>>> a POSIX
>>> point of view, and the way how chmod and file create modes are  
>>> applied to
>>> NFSv4 ACLs is weak and not guaranteed to be correct.
>>
>> I disagree -- see below.
>
> Here are some facts to back my points: Let's assume that a file  
> inherits the
> following ACL when being created (I am using ^(...) here with the  
> meaning of
> "all bitflags except ..."):
>
> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
> 	OWNER@:^(READ_DATA/WRITE_DATA)::DENY
> 	GROUP@:READ_DATA::ALLOW
> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
> 	GROUP@:^READ_DATA::DENY
> 	user@domain:^(READ_DATA/WRITE_DATA)::DENY
> 	EVERYONE@:READ_DATA::ALLOW
>
> This acl is "well structured" in the POSIX sense: OWNER@ will only  
> get the
> owner permissions and none of the other permissions, user@domain  
> and GROUP@
> will only get the permissions intended for them, and only others  
> (neither
> OWNER@ nor user@domain nor GROUP@) will get EVERYONE@ permissions;  
> in other
> words, the acl is even correct for non-monotonic permissions.
>
> According to section 5.1 of draft-ietf-nfsv4-acls [1], the  
> resulting file mode
> permission bits for this acl shall be rw-r--r--. After a chmod or a  
> file
> create, alternate file access control mechanisms must be disabled  
> and only
> additional file access control mechanisms may remain active.  
> According to
> POSIX, additional file access control mechanisms require that no  
> user may be
> granted more permissions than the respective file classes permit.  
> In this
> case, user@domain clearly is not in the File Owner Class.  
> (According to
> POSIX, user@domain must be in the File Group Class.) The  
> user@domain user is
> granted WRITE_DATA though, which is *incorrect* from a POSIX point  
> of view.
>
> Next, let's assume than an ACL contains the following pair of user- 
> provided
> entries:
>
> 	GROUP@:WRITE_DATA::DENY
> 	GROUP@:READ_DATA::ALLOW
>
> Clearly the user's intention is to deny WRITE_DATA access to  
> GROUP@. The
> algorithm to apply a mode to an existing ACL will remove the  
> WRITE_DATA bit
> from the GROUP@:WRITE_DATA::DENY entry when a chmod(..., 0770) is done
> though. This is counter to the user's intention, so I would call  
> that *wrong*
> as well. It also violates the principle of least surprise. There  
> really is no
> safe way to tell user-provided ACL entries from artificially made  
> up ACL
> entries.
>
> draft-ietf-nfsv4-acls is missing a clear classification of ACL  
> entries into
> the File Owner, File Group, and File Other classes. Every ACL entry  
> must be
> in one of the three classes in order to compute appropriate file mode
> permission bits when setting an ACL, and after inheriting  
> permissions. This
> classification also determines which effect chmod will have on an ACL.
>
> So draft-ietf-nfsv4-acls is *incorrect* and *wrong* from a POSIX  
> point of
> view, while my alternative proposal is correct, apart from being  
> simpler to
> implement. I hope that my emails and some background reading (like  
> the file
> access related parts of the POSIX definitions volume [5], a paper that
> explains POSIX ACLs and how they are implemented on Linux [6], and  
> perhaps
> 1003.1e draft 17) will convince you about that.
>
> Note that in traditional POSIX, permissions from multiple file  
> classes will
> never accumulate: each user always is either granted the File Owner
> permission bits, the File Group permission bits, or the File Other  
> permission
> bits. (Additional file access control mechanisms may further limit the
> permissions granted, and alternative file access control mechanisms  
> may
> further limit or extend the permissions granted.) Permissions from  
> multiple
> acl entries accumulate in the NFSv4 ACL model though, and so unless  
> an acl is
> "well structured" in the above sense, permissions from multiple  
> classes may
> accumulate.

Yes, permissions may accumulate, but in the design in the minor  
version doc, after a chmod, any permissions that go beyond the mode  
bits being set will be disabled.  This is done via the algorithm in  
section 3.16.6.3 -  "Applying a Mode to an Existing ACL".  This makes  
sure that the permissions (ACE4_READ_DATA/ACE4_LIST_DIRECTORY,
ACE4_WRITE_DATA/ACE4_WRITE_DATA, ACE4_APPEND_DATA/ 
ACE4_ADD_SUBDIRECTORY and ACE4_EXECUTE... which is what the mode  
defines) that accumulate will NOT go beyond the mode bits being set.

>
>>> I will first try to clarify some of the points I tried to make in
>>> the previous posting and point out deficiencies in
>>> draft-ietf-nfsv4-acls-00. Then I will propose an alternative  
>>> design which
>>> is more correct than introducing DENY entries to mask  
>>> permissions. (As a
>>> bonus, it is easier to implement. too.)
>>>
>>>> On a UNIX system that supports NFSv4 ACLs natively, I think we
>>>> should try to accept as wide a range of NFSv4 ACLs as possible,  
>>>> but we
>>>> must make sure that we can preserve POSIX semantics. In  
>>>> particular, this
>>>> means that ACLs may contain ACEs for users other than OWNER@,  
>>>> GROUP@, and
>>>> EVERYONE@, and that chmod(2) must continue to provide the same  
>>>> kinds of
>>>> guarantees as without NFSv4 ACLs.
>>>>
>>>> I am assuming here that NFSv4 ACLs shall be an additional rather  
>>>> than an
>>>> alternate file access control mechanism in the POSIX sense:  
>>>> Alternate
>>>> file access control mechanisms must ``be enabled only by  
>>>> explicit user
>>>> action, on a per-file basis by the file owner or a user with the
>>>> appropriate privilege'', and must ``be disabled for a file after  
>>>> the file
>>>> permission bits are changed for that file with chmod( )''  
>>>> according to
>>>> POSIX. In other words, newly created files or directories would  
>>>> have
>>>> alternate file access control mechanisms disabled. This would  
>>>> render
>>>> NFSv4 ACLs essentially useless for UNIX processes, because they  
>>>> would
>>>> almost always be disabled, and would only work for remote  
>>>> processes until
>>>> a POSIX process chmods a file or creates a directory, which  
>>>> wouldn't get
>>>> us very far.
>>>
>>> As Sam pointed out, a subset of NFSv4 ACLs maps to an additional  
>>> file
>>> access control mechanism, while the rest goes beyond that, and  
>>> therefore
>>> is an alternate file access control mechanism.
>>
>> Yes -- ALLOW ACEs are alternate file access control, and DENY ACEs
>> are additional file access control.
>
> This classification makes no sense, and it also does not match what  
> you
> propose in section 5.3 of draft-ietf-nfsv4-acls, either: there are  
> acls that
> contain ALLOW entries which are still only an additional file  
> access control
> mechanism, so we really need to classify them as an additional file  
> access
> control mechanism in order to avoid having to disable them during  
> chmod or
> when inheriting permissions.

We clearly have a disagreement what "additional" and "alternate" file  
access control mechanisms mean to NFSv4 ACLs.

Without these fundamental things, we will never be able to reach  
consensus.  So lets try to up-level the discussion and see if we can  
get agreement on what the meanings of these two access control  
mechanisms are in the context of NFSv4...

I know this has been iterated over and over again, but bear with  
me...  hopefully this will give you a better idea of where we're  
coming from.

POSIX defines Additional Access Control Mechanism as follows:
"An implementation-defined mechanism that is layered upon the access  
control mechanisms defined here, but which do not grant permissions  
beyond those defined herein, although they may further restrict them."

POSIX defines Alternate Access Control Mechanisms are as follows:
"An implementation-defined mechanism that is independent of the  
access control mechanisms defined herein, and which if enabled on a  
file may either restrict or extend the permissions of a given user.  
IEEE Std 1003.1-2001 defines when such mechanisms can be enabled and  
when they are disabled."

So, the question that comes to my mind when reading that text is:  
What does it mean when they say "access mechanisms defined herein" in  
both of those definitions?  Well, the access mechanisms defined in  
the POSIX spec are the "File Access Permissions", right?  So, can we  
agree that "access mechanisms defined herein" would be the "File  
Access Permissions"?

Okay, the description of "File Access Permissions" says that "The  
standard file access control mechanism uses the file permission bits..."

So, what are the file permission bits?  They are read, write, execute/ 
search for the File Owner Class, File Group Class and File Other Class.

So, to put this together, Additional access control mechanisms are   
the ability to further restrict the read, write, execute/search  
permissions for the File Owner Class, File Group Class and File Other  
Class.  And, Alternate access control mechanisms are the ability to  
either restrict or extend the read, write, execute/search permissions  
for the File Owner, Group and Other Class.

Now, to classify NFSv4 ACLs into Additional and Alternate access  
control mechanisms...
Since we are only controlling the read, write, execute/search  
permissions, the only permissions we should classify in NFSv4 ACLs  
are the access mask bits that intersect with the file permission bits  
as defined by POSIX.  And for NFSv4 that means the following access  
mask bits are of interest:
ACE4_READ_DATA/ACE4_LIST_DIRECTORY
ACE4_WRITE_DATA/ACE4_WRITE_DATA, ACE4_APPEND_DATA/ACE4_ADD_SUBDIRECTORY
ACE4_EXECUTE.

(Actually, this is where the existing draft-ietf-acl-00 proposal is  
confusing.  It doesn't come right out and say this.  In the write up  
we had the assumptions that this was clear, but I know that it needs  
to be further specified.)

So, now in the NFSv4 ACL sense, Alternate access control mechanisms  
are used to further extend and Additional access control mechanisms  
are used to further restrict the following access mask bits:
ACE4_READ_DATA/ACE4_LIST_DIRECTORY
ACE4_WRITE_DATA/ACE4_WRITE_DATA, ACE4_APPEND_DATA/ACE4_ADD_SUBDIRECTORY
ACE4_EXECUTE.

How would one extend those access mask bits (Alternate)?  By putting  
them in an ALLOW ACE.
How would one restrict those access mask bits (Additional)?  By  
putting them in a DENY ACE.

As far as the other access mask bits...they aren't covered by the  
POSIX File Access Permissions so do they need a classification?  No,  
not really.  (More on this below...)

> If ALLOW ACEs were alternate in general, then we
> would have to disable them all after a chmod, and I think we agree  
> that this
> would make ACLs practically useless in combination with POSIX.
>
> The only classification that makes sense is by the permissions that  
> an ACL
> grants.

I would agree with that, but don't go putting further restrictions on  
us than POSIX defined in the first place.  As said before POSIX only  
defines what should happen with regard to the access control  
mechanisms that layer on top of or extend the *file permission  
bits*.  See more below.

> You have given an example of an ACL that clearly is an additional
> file access control mechanism only. With this kind of  
> classification, a
> significant subset of NFSv4 ACLs can be treated as an additional  
> file access
> control mechanism, which makes them actually useful even when POSIX  
> systems
> and Windows (or other systems with NFSv4 ACLs or similar) interact  
> and both
> change ACLs.


The thing that is still out there is that if you classify ACEs with  
ACE4_READ_DATA, for example, as an additional access control  
mechanism, you will never be able to give a arbitrary user or group  
the ACE4_READ_DATA permission without having the File Class that it  
belongs to also have at least those permissions.  That seems broken  
to me.


>
>>> It is important to understand how POSIX defines additional file
>>> access control mechanisms:
>>>
>>> [] 3.4 Additional File Access Control Mechanism
>>> [] An implementation-defined mechanism that is layered upon the
>>> [] access control mechanisms defined here, but which do not grant
>>> [] permissions beyond those defined herein, although they may  
>>> further
>>> [] restrict them.
>>>
>>> In other words, when a file has just been created and after chmod,
>>> the file mode permission bits define an upper bound to the  
>>> permissions
>>> granted to anyone on the system, and nobody has additional  
>>> permissions.
>>> Additional permissions (as an alternate file access control  
>>> mechanism) may
>>> be enabled explicitly, but the next chmod must disable them again.
>>
>> The use of the word "Additional" is confusing in the above
>> sentence.  :-)  I think you mean "more", or similar, but "Additional"
>> has a very specific meaning which (I think) isn't what you mean.
>
> I indeed meant more permissions as in additional mask bits granted,  
> as opposed
> to an additional file access control mechanism in the sense how  
> POSIX defines
> this term.
>
>>> We can classify the permissions that NFSv4 ACLs grant into  
>>> additional and
>>> alternate mechanisms as follows: everything covered by the POSIX
>>> read/write/execute permissions (such as ACE4_READ_DATA, but also
>>> ACE4_APPEND_DATA) is additional, while everything beyond that  
>>> (such as
>>> ACE4_WRITE_OWNER) is alternate.
>>
>> Note well: this is quite different from draft-ietf-nfsv4-
>> minorversion1-03.txt, i.e. this is an alternate proposal.
>
> Yes, this is a different approach of classifying NFSv4 ACLs into  
> additional
> and alternate file access control mechanisms, which complies to  
> POSIX as well
> as to the current NFSv4 RFC. It conflicts with draft-ietf-nfsv4- 
> acls, and by
> implication with draft-ietf-nfsv4-minorversion1-03 [4], which  
> includes the
> same text.
>
> Note that draft-ietf-nfsv4-acls is inconsistent in itself: the  
> algorithm in
> section 5.3 restricts which permissions an ACL grants by masking  
> permissions
> (which implies that you are classifying by permission as opposed to  
> turning
> off all ALLOW entries),

I give you this.  The wording about the classification of ACEs in  
draft-ietf-nfsv4-acls is not quite sufficient.  As I've said before,  
It makes some important assumptions, but isn't clear as to what those  
are.  It doesn't map to what the algorithm specifies.  With that  
said, it was not meant to be misleading in any way.

As documented in the algorithm definition in section 3.16.6.3 -  
"Applying a Mode to an Existing ACL" of the minor version doc, the  
following is a clarification of the classification:

ALLOW ACEs with ACE4_READ_DATA/ACE4_LIST_DIRECTORY, ACE4_WRITE_DATA/ 
ACE4_ADD_FILE, ACE4_APPEND_DATA/ACE4_ADD_SUBDIRECTORY, and  
ACE4_EXECUTE access mask bits are Alternate security mechanisms.   
These access mask bits will be disabled upon chmod.

DENY ACEs with those access mask bits are Additional access control  
mechanisms.  These access mask bits will be left unchanged  after a  
chmod, unless, as described in 3.16.6.3 it is one of the special  
identifiers, OWNER@, GROUP@, EVERYONE@.

All other access mask bits listed below are outside of the access  
control mechanisms specified by POSIX and are therefore unclassified  
and unrestricted:
ACE4_READ_NAMED_ATTRS
ACE4_WRITE_NAMED_ATTRS
ACE4_DELETE_CHILD
ACE4_READ_ATTRIBUTES
ACE4_WRITE_ATTRIBUTES
ACE4_DELETE
ACE4_READ_ACL
ACE4_WRITE_ACL
ACE4_WRITE_OWNER
ACE4_SYNCHRONIZE

This means that if an ACE defines one of those access mask bits, the  
access granted or denied will remain unchanged after a chmod.


> while section 14.4 says that "the ALLOW type of ACE
> is considered to be an alternate file access control mechanism  
> because it can
> further extend the permissions of a user".
>

Thoughts?

Thanks,
Lisa

[-- Attachment #1.2: Type: text/html, Size: 39771 bytes --]

[-- Attachment #2: Type: text/plain, Size: 375 bytes --]


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

On Tuesday, 11. July 2006 07:42, Sam Falkner wrote:
> >> I think having chmod be functional, i.e. chmod 770 gives write
> >> permission to the owning group, and an "ls -l" shows "rwxrwx---",
> >> would be best by far.
> >
> > It screws you when you want to give the owning group fewer permissions
> > than other users in the File Group Class. This can be worked around by
> > creating a dummy group with no members, or one group that only contains
> > a single user for each user, and changing the owning group of files, but
> > the owning group already has other defined uses in POSIX (think of SETG=
ID
> > for files and directories), and so it's not desirable and not always
> > possible to change the owning group to such a dummy group.
>
> No -- if you want owning group to have fewer permissions than other
> users, you're using an ACL.  You use tools that manipulate ACLs.

Sorry, but while this may look like a good idea at first, it doesn't work v=
ery=20
well. Let's look at an example:

	OWNER@:READ_DATA/WRITE_DATA::ALLOW
	GROUP@:READ_DATA/WRITE_DATA::ALLOW
	user@domain:READ_DATA/WRITE_DATA::ALLOW
	EVERYONE:READ_DATA::ALLOW

The mode is rw-rw-r--. Now we use ACL tools to change the ACL to give the=20
owning group fewer permissions than user@domain as you say:

	OWNER@:READ_DATA/WRITE_DATA::ALLOW
	GROUP@:READ_DATA::ALLOW
	user@domain:READ_DATA/WRITE_DATA::ALLOW
	EVERYONE:READ_DATA::ALLOW

The mode must still be rw-rw-r-- because otherwise, user@domain wouldn't ha=
ve=20
WRITE_DATA access. Now a nasty, evil POSIX application that doesn't know=20
anything about ACLs comes along and does a chmod(file, 0600), chmod(file,=20
0664). What should be the appropriate result? If changing the group file mo=
de=20
permission bits writes through to the GROUP@ entry as you say, then we woul=
d=20
end up with the following *effective* permissions:

	OWNER@:READ_DATA/WRITE_DATA::ALLOW
	GROUP@:READ_DATA/WRITE_DATA::ALLOW
	user@domain:READ_DATA/WRITE_DATA::ALLOW
	EVERYONE:READ_DATA::ALLOW

(The effective permissions are the same no matter how permissions are maske=
d=20
in the ACL, be it via DENY ACEs or via masks. In the case of DENY ACEs, the=
=20
ACL would contain DENY entries, but those wouldn't mask any permissions in=
=20
this case. The example is slightly more difficult to think through with DEN=
Y=20
ACEs because they contain some redudancy and potential for inconsistencies,=
=20
but the result is the same.)

=46rom the POSIX application's point of view, the file has the same permiss=
ions=20
before and after the chmod. The POSIX application cannot be held guilty;=20
after all it doesn't know about ACLs by definition. Yet the acl actually=20
grants more permissions after the chmods, and the change we did to give the=
=20
owning group fewer permissions with ACL tools is lost. This can be quite=20
serious.

We can play the same example with MAY_WRITE vs. MAY_APPEND: if the group fi=
le=20
mode permission bits write through to the owning group permissions, a POSIX=
=20
chmod may convert a MAY_APPEND owning group ACE into a MAY_WRITE owning gro=
up=20
ACE.

> Solaris' POSIX-draft ACLs have the property that chmod works (i.e.
> you can set group permissions), and you use setfacl if you want to
> change other entries. It's perfectly easy to have owning group have=20
> fewer permissions than supplimental users.

That's a bug, and draft 17 of POSIX 1003.1e (withdrawn) has this bug fixed.

> The bottom line is that chmod must set the mode, rather than "set the
> mode, unless there's some sort of ACL thingy, in which case the group
> bits aren't the group bits but are instead the mask bits".

We may be misunderstanding here: I agree that chmod must set the file mode=
=20
(permission bits as well as special bits). The point is that the group file=
=20
mode permission bits can no longer be the same as the owning group=20
permissions with ACLs, or else innocent POSIX applications may cause=20
unintended side effects as in the example.

Andreas

=2D-=20
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

On Tuesday, 11. July 2006 08:17, Sam Falkner wrote:
> On Jul 10, 2006, at 5:50 PM, Andreas Gruenbacher wrote:
> > On Monday, 10. July 2006 15:29, Sam Falkner wrote:
> >> On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:
> >>> On Saturday, 8. July 2006 05:45, Sam Falkner wrote:
> >>>> On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:
> >>>>> On Monday, 3. July 2006 23:10, Andreas Gruenbacher wrote:
> >>>
> >>> Here are some facts to back my points: Let's assume that a file inherits
> >>> the following ACL when being created (I am using ^(...) here with the
> >>> meaning of "all bitflags except ..."):
> >>>
> >>> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
> >>> 	OWNER@:^(READ_DATA/WRITE_DATA)::DENY
> >>> 	GROUP@:READ_DATA::ALLOW
> >>> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
> >>> 	GROUP@:^READ_DATA::DENY
> >>> 	user@domain:^(READ_DATA/WRITE_DATA)::DENY
> >>> 	EVERYONE@:READ_DATA::ALLOW
> >>>
> >>> This acl is "well structured" in the POSIX sense: OWNER@ will only get
> >>> the owner permissions and none of the other permissions, user@domain
> >>> and GROUP@ will only get the permissions intended for them, and only
> >>> others (neither OWNER@ nor user@domain nor GROUP@) will get EVERYONE@
> >>> permissions; in other words, the acl is even correct for non-monotonic
> >>> permissions. 
> >>>
> >>> According to section 5.1 of draft-ietf-nfsv4-acls [1], the resulting
> >>> file mode permission bits for this acl shall be rw-r--r--.
> >>
> >> Your proposal would give this mode: rw-rw-r--.  I think we should
> >> consider this more carefully.
> >>
> >>> After a chmod or a file create, alternate file access control mechanisms
> >>> must be disabled and only additional file access control mechanisms may
> >>> remain active. According to POSIX, additional file access control
> >>> mechanisms require that no user may be granted more permissions than the
> >>> respective file classes permit. In this case, user@domain clearly is not
> >>> in the File Owner Class. (According to POSIX, user@domain must be in the
> >>> File Group Class.) The user@domain user is granted WRITE_DATA though,
> >>> which is *incorrect* from a POSIX point of view.
> >>
> >> No, it is not granted WRITE_DATA after a chmod().  After a chmod 644,
> >> there will be a "user@domain:WRITE_DATA::DENY" prepended.  This is
> >> well defined in the current minorversion1.  So it is not "incorrect
> >> from a POSIX point of view."
> >
> > Now that I look at the example again, I realize that I didn't
> > define the create mode. With create mode 640 or less permissive,
> > everything is fine. Let's assume create mode 664 though: then the file
> > mode permission bits will still come out as rw-r--r--, but the ACL will
> > grant WRITE_DATA to user@domain. That's the case I meant, and this case is
> > not POSIX compliant.
>
> Wrong.  The file mode permission bits will be rw-rw-r--.  There is no
> problem with POSIX compliance.

Ah. And why should that be according to draft-ietf-nfsv4-acls-00? Because the 
group file mode permission bits write through to GROUP@ entries, and so the 
rw- group permissions in the create mask elevate the permissions given to the 
owning group in the ACL?

I hope that my reply from Tue, 11 Jul 2006 10:05:21 +0200 made it clear that 
writing through to the GROUP@ entries causes POSIX applications to 
accidentally remove restrictions from an ACL, and so we really must not do 
that. The same argument applies to writing through to OWNER@ and EVERYONE@ 
entries, by the way. The "The final six ACEs are adjusted according to the 
incoming mode" section of the algorithm described in 5.3 is a really bad 
idea.

> >>> Next, let's assume than an ACL contains the following pair of user-
> >>> provided entries:
> >>>
> >>> 	GROUP@:WRITE_DATA::DENY
> >>> 	GROUP@:READ_DATA::ALLOW
> >>>
> >>> Clearly the user's intention is to deny WRITE_DATA access to GROUP@.
> >>
> >> Yes, that *was* the user's intention, at the time the user set the
> >> ACL.
> >
> > Hm... not the best example because GROUP@ is the owning group, which
> > corresponds to the group file mode permission bits in traditional
> > POSIX. The problem is more difficult to see in this case, but I argue
> > that the owhning group permissions and the group file mode permission
> > bits are not the same with ACLs: the file group mode permission bits
> > restrict GROUP@ entries, and all user@domain and group@domain entries
> > in the acl. For the sake of this example, substitute GROUP@ with
> > user@domain though, and you'll see the problem more clearly: a user
> > adds an explicit user@domain:WRITE_DATA::DENY entry to an acl which
> > is followed by a user@domain:READ_DATA::ALLOW entry. After a chmod to
> > 664 for example, this user suddenly has write access. The
> > user clearly did not intend this to happen.
>
> No -- after the chmod, the DENY still stands, unaltered.

Great Sam, you have trapped me with another special case that is there only 
because of those pesky mask DENY entries: "the mask bits are a subset of the 
mask bits of the current ACE" [1].

My point still holds, just that the following ALLOW ACE must have the denied 
WRITE_DATA permission set as well:

	user@domain:WRITE_DATA::DENY
	user@domain:READ_DATA/WRITE_DATA::ALLOW

Do you *still* disagree?

Andreas

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

On Tuesday, 11. July 2006 08:50, Lisa Week wrote:
> On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:
> > Note that in traditional POSIX, permissions from multiple file
> > classes will never accumulate: each user always is either granted the
> > File Owner permission bits, the File Group permission bits, or the File
> > Other permission bits. (Additional file access control mechanisms may
> > further limit the permissions granted, and alternative file access
> > control mechanisms may further limit or extend the permissions granted.)
> > Permissions from multiple acl entries accumulate in the NFSv4 ACL model
> > though, and so unless an acl is "well structured" in the above sense,
> > permissions from multiple classes may accumulate.
>
> Yes, permissions may accumulate, but in the design in the minor
> version doc, after a chmod, any permissions that go beyond the mode
> bits being set will be disabled.  This is done via the algorithm in
> section 3.16.6.3 -  "Applying a Mode to an Existing ACL".  This makes
> sure that the permissions (ACE4_READ_DATA/ACE4_LIST_DIRECTORY,
> ACE4_WRITE_DATA/ACE4_WRITE_DATA, ACE4_APPEND_DATA/
> ACE4_ADD_SUBDIRECTORY and ACE4_EXECUTE... which is what the mode
> defines) that accumulate will NOT go beyond the mode bits being set.

Ack.

Andreas


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Sam Falkner]

On Jul 11, 2006, at 4:05 AM, Andreas Gruenbacher wrote:

> On Tuesday, 11. July 2006 07:42, Sam Falkner wrote:
>>>> I think having chmod be functional, i.e. chmod 770 gives write
>>>> permission to the owning group, and an "ls -l" shows "rwxrwx---",
>>>> would be best by far.
>>>
>>> It screws you when you want to give the owning group fewer  
>>> permissions
>>> than other users in the File Group Class. This can be worked  
>>> around by
>>> creating a dummy group with no members, or one group that only  
>>> contains
>>> a single user for each user, and changing the owning group of  
>>> files, but
>>> the owning group already has other defined uses in POSIX (think  
>>> of SETGID
>>> for files and directories), and so it's not desirable and not always
>>> possible to change the owning group to such a dummy group.
>>
>> No -- if you want owning group to have fewer permissions than other
>> users, you're using an ACL.  You use tools that manipulate ACLs.
>
> Sorry, but while this may look like a good idea at first, it  
> doesn't work very
> well. Let's look at an example:
>
> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
> 	GROUP@:READ_DATA/WRITE_DATA::ALLOW
> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
> 	EVERYONE:READ_DATA::ALLOW
>
> The mode is rw-rw-r--. Now we use ACL tools to change the ACL to  
> give the
> owning group fewer permissions than user@domain as you say:
>
> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
> 	GROUP@:READ_DATA::ALLOW
> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
> 	EVERYONE:READ_DATA::ALLOW

> The mode must still be rw-rw-r-- because otherwise, user@domain  
> wouldn't have
> WRITE_DATA access. Now a nasty, evil POSIX application that doesn't  
> know
> anything about ACLs comes along and does a chmod(file, 0600), chmod 
> (file,
> 0664). What should be the appropriate result? If changing the group  
> file mode
> permission bits writes through to the GROUP@ entry as you say, then  
> we would
> end up with the following *effective* permissions:
>
> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
> 	GROUP@:READ_DATA/WRITE_DATA::ALLOW
> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
> 	EVERYONE:READ_DATA::ALLOW

That's not how Solaris works either.  Sorry, I should have explained  
it better.  In Solaris using POSIX-draft ACLs, chmod() changes both  
the group permissions and the mask, simultaneously.  I now understand  
why you were hesitant to have chmod affect the group permissions, but  
having it affect both mask and group solves both problems.

I realize that I'm talking about POSIX-draft ACLs, but the same  
design principles work for NFSv4 ACLs.  chmod() affects the GROUP@  
permissions directly, and also affects the mask, no matter how the  
mask is implemented.

- Sam


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Sam Falkner]

On Jul 11, 2006, at 4:45 AM, Andreas Gruenbacher wrote:

> On Tuesday, 11. July 2006 08:17, Sam Falkner wrote:
>> On Jul 10, 2006, at 5:50 PM, Andreas Gruenbacher wrote:
>>> On Monday, 10. July 2006 15:29, Sam Falkner wrote:
>>>> On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:
>>>>> On Saturday, 8. July 2006 05:45, Sam Falkner wrote:
>>>>>> On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:
>>>>>>> On Monday, 3. July 2006 23:10, Andreas Gruenbacher wrote:
>>>>>
>>>>> Here are some facts to back my points: Let's assume that a file  
>>>>> inherits
>>>>> the following ACL when being created (I am using ^(...) here  
>>>>> with the
>>>>> meaning of "all bitflags except ..."):
>>>>>
>>>>> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
>>>>> 	OWNER@:^(READ_DATA/WRITE_DATA)::DENY
>>>>> 	GROUP@:READ_DATA::ALLOW
>>>>> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
>>>>> 	GROUP@:^READ_DATA::DENY
>>>>> 	user@domain:^(READ_DATA/WRITE_DATA)::DENY
>>>>> 	EVERYONE@:READ_DATA::ALLOW
>>>>>
>>>>> This acl is "well structured" in the POSIX sense: OWNER@ will  
>>>>> only get
>>>>> the owner permissions and none of the other permissions,  
>>>>> user@domain
>>>>> and GROUP@ will only get the permissions intended for them, and  
>>>>> only
>>>>> others (neither OWNER@ nor user@domain nor GROUP@) will get  
>>>>> EVERYONE@
>>>>> permissions; in other words, the acl is even correct for non- 
>>>>> monotonic
>>>>> permissions.
>>>>>
>>>>> According to section 5.1 of draft-ietf-nfsv4-acls [1], the  
>>>>> resulting
>>>>> file mode permission bits for this acl shall be rw-r--r--.
>>>>
>>>> Your proposal would give this mode: rw-rw-r--.  I think we should
>>>> consider this more carefully.
>>>>
>>>>> After a chmod or a file create, alternate file access control  
>>>>> mechanisms
>>>>> must be disabled and only additional file access control  
>>>>> mechanisms may
>>>>> remain active. According to POSIX, additional file access control
>>>>> mechanisms require that no user may be granted more permissions  
>>>>> than the
>>>>> respective file classes permit. In this case, user@domain  
>>>>> clearly is not
>>>>> in the File Owner Class. (According to POSIX, user@domain must  
>>>>> be in the
>>>>> File Group Class.) The user@domain user is granted WRITE_DATA  
>>>>> though,
>>>>> which is *incorrect* from a POSIX point of view.
>>>>
>>>> No, it is not granted WRITE_DATA after a chmod().  After a chmod  
>>>> 644,
>>>> there will be a "user@domain:WRITE_DATA::DENY" prepended.  This is
>>>> well defined in the current minorversion1.  So it is not "incorrect
>>>> from a POSIX point of view."
>>>
>>> Now that I look at the example again, I realize that I didn't
>>> define the create mode. With create mode 640 or less permissive,
>>> everything is fine. Let's assume create mode 664 though: then the  
>>> file
>>> mode permission bits will still come out as rw-r--r--, but the  
>>> ACL will
>>> grant WRITE_DATA to user@domain. That's the case I meant, and  
>>> this case is
>>> not POSIX compliant.
>>
>> Wrong.  The file mode permission bits will be rw-rw-r--.  There is no
>> problem with POSIX compliance.
>
> Ah. And why should that be according to draft-ietf-nfsv4-acls-00?  
> Because the
> group file mode permission bits write through to GROUP@ entries,  
> and so the
> rw- group permissions in the create mask elevate the permissions  
> given to the
> owning group in the ACL?
>
> I hope that my reply from Tue, 11 Jul 2006 10:05:21 +0200 made it  
> clear that
> writing through to the GROUP@ entries causes POSIX applications to
> accidentally remove restrictions from an ACL, and so we really must  
> not do
> that. The same argument applies to writing through to OWNER@ and  
> EVERYONE@
> entries, by the way. The "The final six ACEs are adjusted according  
> to the
> incoming mode" section of the algorithm described in 5.3 is a  
> really bad
> idea.
>
>>>>> Next, let's assume than an ACL contains the following pair of  
>>>>> user-
>>>>> provided entries:
>>>>>
>>>>> 	GROUP@:WRITE_DATA::DENY
>>>>> 	GROUP@:READ_DATA::ALLOW
>>>>>
>>>>> Clearly the user's intention is to deny WRITE_DATA access to  
>>>>> GROUP@.
>>>>
>>>> Yes, that *was* the user's intention, at the time the user set the
>>>> ACL.
>>>
>>> Hm... not the best example because GROUP@ is the owning group, which
>>> corresponds to the group file mode permission bits in traditional
>>> POSIX. The problem is more difficult to see in this case, but I  
>>> argue
>>> that the owhning group permissions and the group file mode  
>>> permission
>>> bits are not the same with ACLs: the file group mode permission bits
>>> restrict GROUP@ entries, and all user@domain and group@domain  
>>> entries
>>> in the acl. For the sake of this example, substitute GROUP@ with
>>> user@domain though, and you'll see the problem more clearly: a user
>>> adds an explicit user@domain:WRITE_DATA::DENY entry to an acl which
>>> is followed by a user@domain:READ_DATA::ALLOW entry. After a  
>>> chmod to
>>> 664 for example, this user suddenly has write access. The
>>> user clearly did not intend this to happen.
>>
>> No -- after the chmod, the DENY still stands, unaltered.
>
> Great Sam, you have trapped me with another special case that is  
> there only
> because of those pesky mask DENY entries: "the mask bits are a  
> subset of the
> mask bits of the current ACE" [1].

I trapped you, but not out of malice.  The fact that you fell into  
the trap proves a point.  You tried to give an example as a  
reasonable pair of ACEs that a user would set, and fell into the trap  
of having the design deal with your ACEs correctly.  The design is to  
only manipulate DENY entries if the follow a very specific pattern, a  
pattern that an end-user is unlikely to set.  In other words, the  
design avoids manipulating DENYs unless the DENYs are redundant.

> My point still holds, just that the following ALLOW ACE must have  
> the denied
> WRITE_DATA permission set as well:
>
> 	user@domain:WRITE_DATA::DENY
> 	user@domain:READ_DATA/WRITE_DATA::ALLOW

Yes, there, the chmod would change the DENY ACE.  So if an end-user  
really did say WRITE_DATA:DENY, WRITE_DATA:ALLOW, albeit with other  
bits, then yes, the ACL can change as a result of the chmod.

> Do you *still* disagree?

I don't disagree that the DENY would be changed by a chmod(), but I  
do disagree that it's a major flaw.

I would rather live with the flaw of having redundant user-supplied  
ACEs manipulated upon chmod than to add new file attributes that  
NFSv4.0 clients and servers won't know about.

- Sam


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[J. Bruce Fields]

On Tue, Jul 11, 2006 at 08:29:21AM -0400, Sam Falkner wrote:
> That's not how Solaris works either.  Sorry, I should have explained  
> it better.  In Solaris using POSIX-draft ACLs, chmod() changes both  
> the group permissions and the mask, simultaneously.  I now understand  
> why you were hesitant to have chmod affect the group permissions, but  
> having it affect both mask and group solves both problems.

I think you're missing the point of his example.  The point is that a
chmod-using application may expect the sequence chmod(600) chmod(664) on
a file with mode 664 to be a no-op.

But if chmod() changes both group and mask bits ("owning group" and
"group file class" bits) then this sequence isn't a no-op any more in
his example.  It gives GROUP@ write permissions.

So Andreas is trying to ensure the property that any sequence of chmod's
that leaves the mode bits the same also leaves the ACL the same.  I
agree that that's a nice property.

What I'm not convinced of yet is that this is really worth caring about
much.  Is this common application behavior?  Have there been complaints
about this from people using Solaris's ACLs?

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: [NFS] NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[J. Bruce Fields]

On Fri, Jul 07, 2006 at 01:55:30PM +0200, Andreas Gruenbacher wrote:
> On Monday, 3. July 2006 23:10, Andreas Gruenbacher wrote:
> > I have been thinking about the problems of interaction between NFSv4 ACLs
> > and POSIX, and particularly about the issue of masking permissions through
> > chmod and after creating files or directories.

So, omitting the details, the idea is to add 3 optional attributes
(owner_class_mask, group_class_mask, and other_class_mask) which limit
the permissions that an ACL can grant to different classes of entities.

For a client that doesn't support the new attributes, a server can apply
the mask attributes to the ACL before returning it.  I suppose a
multi-protocol server would do the same for CIFS clients.

For a server that doesn't support the new attributes, the client still
has available any of the current options: give up on non-destructive
chmod, or fall back on representing mask bits with DENIES.

When client and server support the new mask bits, we get a completely
non-destructive chmod without all the complicated DENY heuristics.

I agree that that would be an improvement.

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: Re: [NFS] NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[J. Bruce Fields]

On Fri, Jul 14, 2006 at 01:59:30PM -0400, J. Bruce Fields wrote:
> For a client that doesn't support the new attributes, a server can apply
> the mask attributes to the ACL before returning it.  I suppose a
> multi-protocol server would do the same for CIFS clients.

By the way, the proposed protocol behavior here is odd:  the server
returns a different ACL depending on whether the client requested any of
the new mask attributes in the same GETATTR.

But I suppose there are other cases (rdattr_error, maybe some migration
cases??) where what we return can depend in strange ways on which
attributes were requested, so maybe it's not totally without precedent?

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: Re: [NFS] NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

On Friday, 14. July 2006 19:59, J. Bruce Fields wrote:
> For a server that doesn't support the new attributes, the client still
> has available any of the current options: give up on non-destructive
> chmod, or fall back on representing mask bits with DENIES.

Maybe not what you meant, but shouldn't the client rely on the server to do 
"the right thing" when it sees a mode SETATTR? I think it would be a bad idea 
for the client to guess such details as which exact file security model a 
server implements. Instead, the server should be responsible for doing what 
the client is asking for (and erring towards more restrictive permissions if 
necessary).

Andreas

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: Re: [NFS] NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[J. Bruce Fields]

On Fri, Jul 14, 2006 at 09:02:44PM +0200, Andreas Gruenbacher wrote:
> On Friday, 14. July 2006 19:59, J. Bruce Fields wrote:
> > For a server that doesn't support the new attributes, the client still
> > has available any of the current options: give up on non-destructive
> > chmod, or fall back on representing mask bits with DENIES.
> 
> Maybe not what you meant, but shouldn't the client rely on the server to do 
> "the right thing" when it sees a mode SETATTR?

RFC 3530 allows a server to leave named users and groups with
permissions greater than the permissions in the group mode bit, so if a
client wants posix-like behavior it can't count on the server for that.

That said...

> I think it would be a bad idea for the client to guess such details as
> which exact file security model a server implements. Instead, the
> server should be responsible for doing what the client is asking for
> (and erring towards more restrictive permissions if necessary).

... I'm all for declaring 3530 wrong here and insisting that the mode bits
act like a mask, or just not worrying about it and telling users to
check their server's manual very carefully if they depend on the posix
behavior.

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Sam Falkner]

On Jul 11, 2006, at 9:46 AM, J. Bruce Fields wrote:

> On Tue, Jul 11, 2006 at 08:29:21AM -0400, Sam Falkner wrote:
>> That's not how Solaris works either.  Sorry, I should have explained
>> it better.  In Solaris using POSIX-draft ACLs, chmod() changes both
>> the group permissions and the mask, simultaneously.  I now understand
>> why you were hesitant to have chmod affect the group permissions, but
>> having it affect both mask and group solves both problems.
>
> I think you're missing the point of his example.  The point is that a
> chmod-using application may expect the sequence chmod(600) chmod 
> (664) on
> a file with mode 664 to be a no-op.
>
> But if chmod() changes both group and mask bits ("owning group" and
> "group file class" bits) then this sequence isn't a no-op any more in
> his example.  It gives GROUP@ write permissions.

Okay, understood.

> So Andreas is trying to ensure the property that any sequence of  
> chmod's
> that leaves the mode bits the same also leaves the ACL the same.  I
> agree that that's a nice property.

Perhaps, but I think having chmod unable to set the mode to be a much  
more undesirable property, to put it mildly.

> What I'm not convinced of yet is that this is really worth caring  
> about
> much.  Is this common application behavior?  Have there been  
> complaints
> about this from people using Solaris's ACLs?

I did some more research, and found that the Solaris chmod() system  
call does pretty much what Linux does -- the group permissions of  
chmod() affect the mask, not the group permission bits.  Originally,  
the chmod command did the chmod() system call, and not much else.

There were many complaints about this.  So many that the chmod  
command line was changed to do the chmod() system call, and then, in  
the presence of an ACL, fix the permission bits.  In other words, the  
bug was fixed.

I have found no complaints about the current Solaris behavior, where  
chmod affects group permissions.

- Sam


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

Lisa,

On Tuesday, 11. July 2006 08:50, Lisa Week wrote:
> POSIX defines Additional Access Control Mechanism as follows:
> "An implementation-defined mechanism that is layered upon the access
> control mechanisms defined here, but which do not grant permissions
> beyond those defined herein, although they may further restrict them."
>
> POSIX defines Alternate Access Control Mechanisms are as follows:
> "An implementation-defined mechanism that is independent of the
> access control mechanisms defined herein, and which if enabled on a
> file may either restrict or extend the permissions of a given user.
> IEEE Std 1003.1-2001 defines when such mechanisms can be enabled and
> when they are disabled."
>
> So, the question that comes to my mind when reading that text is:
> What does it mean when they say "access mechanisms defined herein" in
> both of those definitions?  Well, the access mechanisms defined in
> the POSIX spec are the "File Access Permissions", right?  So, can we
> agree that "access mechanisms defined herein" would be the "File
> Access Permissions"?

the "access mechanisms defined herein" refer to all file access control 
mechanisms that POSIX defines. This includes permissions always granted to 
the owner such as chmod, but also mechanisms such as the restricted deletion 
flag bit (S_ISVTX) for directories, etc.

Trust me, POSIX is very careful about wording, and if "access mechanisms 
defined herein" did indeed refer to the file access permissions, then POSIX 
would say exactly that.

> I give you this.  The wording about the classification of ACEs in
> draft-ietf-nfsv4-acls is not quite sufficient.  As I've said before,
> It makes some important assumptions, but isn't clear as to what those
> are. It doesn't map to what the algorithm specifies.  With that 
> said, it was not meant to be misleading in any way.

I never meant to imply bad intentions ;-)

> As documented in the algorithm definition in section 3.16.6.3 -
> "Applying a Mode to an Existing ACL" of the minor version doc, the
> following is a clarification of the classification:
>
> ALLOW ACEs with ACE4_READ_DATA/ACE4_LIST_DIRECTORY, ACE4_WRITE_DATA/
> ACE4_ADD_FILE, ACE4_APPEND_DATA/ACE4_ADD_SUBDIRECTORY, and
> ACE4_EXECUTE access mask bits are Alternate security mechanisms.
> These access mask bits will be disabled upon chmod.
>
> DENY ACEs with those access mask bits are Additional access control
> mechanisms.  These access mask bits will be left unchanged  after a
> chmod, unless, as described in 3.16.6.3 it is one of the special
> identifiers, OWNER@, GROUP@, EVERYONE@.

No, that's still messed up. We don't care about permissions that are not 
granted, so we *could* only look at ALLOW ACEs, but this distinction is not 
at all relevant.

What counts is which access mask flags are equivalent to the POSIX Read, 
Write, and Execute permissions, and which are not: those are the access mask 
flags which may (sometimes) be used as additional access control mechanisms.

The other issue is which POSIX file class each ACE maps to. Let's assume for 
now that we only know that OWNER@ maps to the File Owner Class to keep this 
example short.

Together with these two classifications, we can determine whether an ACE is 
within the bounds of an additional file access control mechanism. Let's look 
at the following ACE, and a file which has a file mode of 0740 (rwxr-----):

  OWNER@:READ_DATA/APPEND_DATA/EXECUTE::ALLOW

The OWNER@ ACE maps to the File Owner Class. This means that as an additional 
access control mechanism, the ACE may not grant more than Read, Write, and 
Execute. The READ_DATA access mask flag is equivalent to POSIX Read, the 
APPEND_DATA access mask flag is a subset of POSIX Write, and the EXECUTE 
access mask flag is equivalent to POSIX Execute, so we are fine.

Now, let's assume that the user does a chmod to mode 0640 (rw-r-----). The 
permissions of the File Owner Class now no longer cover the EXECUTE 
permission. There are two options to fix this problem:

 1. either accept that the ACE cannot be part of an additional file
    access control mechanism, or

 2. disable the EXECUTE access mask flag, either temporarily or
    permanently, which gets us back into the bounds of additional file
    access control mechanisms.

In case 1, the only choice that remains is that the ACE must be part of an 
alternate file access control mechanism (see more on that below). POSIX 
states that we must disable alternate file access control mechanisms upon 
chmod and for new files, and they must only be re-enabled per explicit user 
action. So the EXECUTE permission would be just gone until the user 
explicitly re-enables it (with something other than a chmod). This would 
render ACLs practically useless under POSIX.

In case 2, the ACE still remains within the bounds of additional file access 
control mechanisms. If we disable EXECUTE only temporarily, then a future 
chmod back to mode 0740 can simply re-enable EXECUTE, and we will not have 
lost anything. (Remember, chmod does not disable additional file access 
control mechanisms.) 

There are several possibilities how we can disable access mode flags 
temporarily:

 1. we could add an explicit DENY ACE before the ALLOW ACE that has
    the affected access mask flags disabled (this is the
    draft-ietf-nfsv4-acls-00 approach),

 2. we could declare that all access mask flags which go beyond
    the corresponding File Class are automatically disabled, or

 3. we could introduce file masks as I am proposing.

The file masks have the advantage that the user can easily manually enable 
more access mask flags in them. This would construe an explicit user action 
as per POSIX. So depending on which flags the user enables, that may amount 
to an additional or alternate file access control mechanism. POSIX is 
perfectly fine with that, even for enabling flags such as WRITE_OWNER. The 
only thing we must ensure is that alternate flags are disabled upon chmod as 
well as for new files.

> All other access mask bits listed below are outside of the access
> control mechanisms specified by POSIX and are therefore unclassified
> and unrestricted:
> ACE4_READ_NAMED_ATTRS
> ACE4_WRITE_NAMED_ATTRS
> ACE4_DELETE_CHILD
> ACE4_READ_ATTRIBUTES
> ACE4_WRITE_ATTRIBUTES
> ACE4_DELETE
> ACE4_READ_ACL
> ACE4_WRITE_ACL
> ACE4_WRITE_OWNER
> ACE4_SYNCHRONIZE
>
> This means that if an ACE defines one of those access mask bits, the
> access granted or denied will remain unchanged after a chmod.

I am afraid this is impossible: there is no such thing as being outside the 
file access control mechanisms defined by POSIX. The reason is simple: POSIX 
applications absolutely *must* be able to rely on POSIX semantics in order to 
be able to keep the system secure.

Let's assume that ACE4_WRITE_OWNER was indeed outside of the access control 
mechanisms defined by POSIX as a counter example. A POSIX application does a 
chmod to mode 0600 (rw-------) in order to restrict access to the file owner. 
After that, the application can perfectly well write information that is 
confidential to the owner into the file -- after all, only the owner will 
have access, right?

Well, not quite, because an ACL might still grant ACE4_WRITE_OWNER to some 
other user on the system. That other user could simply take over ownership of 
the file, and do whatever he wants with it. Here we have it, a perfect 
security hole; all POSIX applications potentially broken!

Therefore, there cannot be any file access control mechanisms which are 
neither defined by POSIX, nor additional or alternate.

By definition, pure POSIX applications have no idea which additional or 
alternate file access control mechanisms a particular POSIX implementation 
may define, so they cannot know about such sideband mechanisms, and they also 
have no way of disabling them.

Andreas

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

Lisa,

On Thursday, 27. July 2006 02:59, Andreas Gruenbacher wrote:
> Let's assume that ACE4_WRITE_OWNER was indeed outside of the access control
> mechanisms defined by POSIX as a counter example. A POSIX application does
> a chmod to mode 0600 (rw-------) in order to restrict access to the file
> owner. After that, the application can perfectly well write information
> that is confidential to the owner into the file -- after all, only the
> owner will have access, right?
>
> Well, not quite, because an ACL might still grant ACE4_WRITE_OWNER to some
> other user on the system. That other user could simply take over ownership
> of the file, and do whatever he wants with it. Here we have it, a perfect
> security hole; all POSIX applications potentially broken!
>
> Therefore, there cannot be any file access control mechanisms which are
> neither defined by POSIX, nor additional or alternate.

I forgot to mention that an analogous case can be made for additional file 
access control mechanisms as well: POSIX applications cannot know which 
additional file access control mechanisms a particular implementation may 
support; they are free to rely on invariants under POSIX, such as a chmod 
from one mode to another, which should be a no-op. Additional file access 
control mechanisms must make sure that POSIX invariants will not change the 
permissions granted.

This contradicts with having a chmod write through to OWNER@, GROUP@, and 
EVERYONE@ ACEs: consider the same ACE we had before with a file mode of 0740 
(rwxr-----):

  OWNER@:READ_DATA/APPEND_DATA/EXECUTE::ALLOW

If a chmod to 0640 and back to 0740 writes through to the OWNER@ ACE, the 
entry will change to:

  OWNER@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW

So a POSIX application has added mask flags in a supposed invariant. That's 
also a security hole, but not one as severe as the first because the only 
mask flag affected is APPEND_DATA (I believe).

I have pointed this out before in Section 4.7. "Mode Changes and the OWNER@, 
GROUP@, and EVERYONE@ ACEs".

Andreas

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Lisa Week]

Hi Andreas,

Some initial comments inline...

Thanks,
Lisa

Andreas Gruenbacher wrote:

>Lisa,
>
>On Tuesday, 11. July 2006 08:50, Lisa Week wrote:
>  
>
>>POSIX defines Additional Access Control Mechanism as follows:
>>"An implementation-defined mechanism that is layered upon the access
>>control mechanisms defined here, but which do not grant permissions
>>beyond those defined herein, although they may further restrict them."
>>
>>POSIX defines Alternate Access Control Mechanisms are as follows:
>>"An implementation-defined mechanism that is independent of the
>>access control mechanisms defined herein, and which if enabled on a
>>file may either restrict or extend the permissions of a given user.
>>IEEE Std 1003.1-2001 defines when such mechanisms can be enabled and
>>when they are disabled."
>>
>>So, the question that comes to my mind when reading that text is:
>>What does it mean when they say "access mechanisms defined herein" in
>>both of those definitions?  Well, the access mechanisms defined in
>>the POSIX spec are the "File Access Permissions", right?  So, can we
>>agree that "access mechanisms defined herein" would be the "File
>>Access Permissions"?
>>    
>>
>
>the "access mechanisms defined herein" refer to all file access control 
>mechanisms that POSIX defines. This includes permissions always granted to 
>the owner such as chmod, but also mechanisms such as the restricted deletion 
>flag bit (S_ISVTX) for directories, etc.
>
>Trust me, POSIX is very careful about wording, and if "access mechanisms 
>defined herein" did indeed refer to the file access permissions, then POSIX 
>would say exactly that.
>
>  
>
>>As documented in the algorithm definition in section 3.16.6.3 -
>>"Applying a Mode to an Existing ACL" of the minor version doc, the
>>following is a clarification of the classification:
>>
>>ALLOW ACEs with ACE4_READ_DATA/ACE4_LIST_DIRECTORY, ACE4_WRITE_DATA/
>>ACE4_ADD_FILE, ACE4_APPEND_DATA/ACE4_ADD_SUBDIRECTORY, and
>>ACE4_EXECUTE access mask bits are Alternate security mechanisms.
>>These access mask bits will be disabled upon chmod.
>>
>>DENY ACEs with those access mask bits are Additional access control
>>mechanisms.  These access mask bits will be left unchanged  after a
>>chmod, unless, as described in 3.16.6.3 it is one of the special
>>identifiers, OWNER@, GROUP@, EVERYONE@.
>>    
>>
>
>No, that's still messed up. We don't care about permissions that are not 
>granted, so we *could* only look at ALLOW ACEs, but this distinction is not 
>at all relevant.
>  
>
What?  I don't understand how you can say that "we don't care about 
permissions that are not granted".  We definitely care about permissions 
that are explicitly not granted. 

Also, I believe it is relevant to make a distinction between ALLOW and 
DENY ACEs.  Here's why:

The reasoning behind classifying those DENY ACEs as additional access 
control mechanisms are 1.) because they further restrict the permissions 
of users and groups (which is what additional does by definition) and 
2.) we don't want them to have to be disabled upon chmod.  Try to think 
about it in a way that you have just set an explicit entry to deny 
certain permissions to a supplemental user or group.  It is important 
that those users or groups don't have their permissions elevated after 
chmod.

For example, if you have an ACL such as this:

fred:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::DENY
OWNER@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
GROUP@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
EVERYONE@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW


The mode would be 777.  User fred is denied the ability to read, write 
and execute because of the explicit deny ACE.  After chmod, fred should 
still not be able to read, write and execute.  That is the goal that we 
were trying to meet.

I realize that the mapping that you describe in section 4.4 of 
http://www.suse.de/~agruen/nfs4acl/mapping-nfsv4-acls-to-posix-00.html 
would also give us the capabilities that  I have described above.

With that said, I will go on to describe the capabilities that I feel 
the mapping in section 4.4 lacks.  The capabilities that it lacks is 
where the relevance of having those ALLOW ACEs that I described before 
be considered Alternate access control mechanisms comes in.

The mapping in section 4.4 makes it impossible to do the following by 
*only* modifying the ACL.

The mode of the file is 644 and you want to give fred the ability to 
read, write and execute.

fred:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
OWNER@:READ_DATA/WRITE_DATA/APPEND_DATA::ALLOW
OWNER@:EXECUTE::DENY
GROUP@:READ_DATA::ALLOW
GROUP@:WRITE_DATA/APPEND_DATA/EXECUTE::DENY
EVERYONE@:READ_DATA::ALLOW
EVERYONE@:WRITE_DATA/APPEND_DATA/EXECUTE::DENY

With the classification in 4.4, you can set that ACL, but it won't take 
effect until you also explicitly modify the file group class permissions 
(via a mask or whatever).

The capability to set the type of ACL that is above was the goal when 
classifying ALLOW ACEs as Alternate security access control mechanisms.  
We can do this because as Alternate is defined, it can extend the 
permissions of a user.  Therefore, setting the ACL attribute is all that 
is needed for this to take effect.

---

I am trying to figure out why there has been such a disagreement here 
and perhaps this is another thing that needs to be cleared up.  What 
does the disabling of an alternate access control mechanism mean?  
Certainly it is not that we have to get rid of everything that is in an 
ALLOW ACE every time a chmod is done.

If you had the following ACL:

fred:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
OWNER@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
GROUP@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
EVERYONE@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW

The mode would be 777.  Disabling can be meant that after the chmod, the 
user "fred" should not have more permissions that his respective class.  
So, after a chmod to 770, fred should still be allowed the ability to 
read, write and execute.  This is in how the permissions for fred are 
disabled.  They are being masked down to what the permissions of the 
file group class are.

>What counts is which access mask flags are equivalent to the POSIX Read, 
>Write, and Execute permissions, and which are not: those are the access mask 
>flags which may (sometimes) be used as additional access control mechanisms.
>  
>

What do you mean by sometimes.

>The other issue is which POSIX file class each ACE maps to. Let's assume for 
>now that we only know that OWNER@ maps to the File Owner Class to keep this 
>example short.
>
>Together with these two classifications, we can determine whether an ACE is 
>within the bounds of an additional file access control mechanism. Let's look 
>at the following ACE, and a file which has a file mode of 0740 (rwxr-----):
>
>  OWNER@:READ_DATA/APPEND_DATA/EXECUTE::ALLOW
> 
>
>The OWNER@ ACE maps to the File Owner Class. This means that as an additional 
>access control mechanism, the ACE may not grant more than Read, Write, and 
>Execute. The READ_DATA access mask flag is equivalent to POSIX Read, the 
>APPEND_DATA access mask flag is a subset of POSIX Write, and the EXECUTE 
>access mask flag is equivalent to POSIX Execute, so we are fine.
>
>Now, let's assume that the user does a chmod to mode 0640 (rw-r-----). The 
>permissions of the File Owner Class now no longer cover the EXECUTE 
>permission. There are two options to fix this problem:
>
> 1. either accept that the ACE cannot be part of an additional file
>    access control mechanism, or
>
> 2. disable the EXECUTE access mask flag, either temporarily or
>    permanently, which gets us back into the bounds of additional file
>    access control mechanisms.
>
>In case 1, the only choice that remains is that the ACE must be part of an 
>alternate file access control mechanism (see more on that below). POSIX 
>states that we must disable alternate file access control mechanisms upon 
>chmod and for new files, and they must only be re-enabled per explicit user 
>action. So the EXECUTE permission would be just gone until the user 
>explicitly re-enables it (with something other than a chmod). This would 
>render ACLs practically useless under POSIX.
>  
>

Why wouldn't the EXECUTE permission be able to be re-enabled with 
chmod?  Of course, it can.  If you are setting a mode of 740, that says 
that the owner can execute.  That is an explicit action and EXECUTE 
permission should be granted to the owner.

>In case 2, the ACE still remains within the bounds of additional file access 
>control mechanisms. If we disable EXECUTE only temporarily, then a future 
>chmod back to mode 0740 can simply re-enable EXECUTE, and we will not have 
>lost anything. (Remember, chmod does not disable additional file access 
>control mechanisms.)
>

> 
>
>There are several possibilities how we can disable access mode flags 
>temporarily:
>
> 1. we could add an explicit DENY ACE before the ALLOW ACE that has
>    the affected access mask flags disabled (this is the
>    draft-ietf-nfsv4-acls-00 approach),
>
> 2. we could declare that all access mask flags which go beyond
>    the corresponding File Class are automatically disabled, or
>
> 3. we could introduce file masks as I am proposing.
>
>The file masks have the advantage that the user can easily manually enable 
>more access mask flags in them. This would construe an explicit user action 
>as per POSIX. So depending on which flags the user enables, that may amount 
>to an additional or alternate file access control mechanism. POSIX is 
>perfectly fine with that, even for enabling flags such as WRITE_OWNER. The 
>only thing we must ensure is that alternate flags are disabled upon chmod as 
>well as for new files.
>
>  
>
>>All other access mask bits listed below are outside of the access
>>control mechanisms specified by POSIX and are therefore unclassified
>>and unrestricted:
>>ACE4_READ_NAMED_ATTRS
>>ACE4_WRITE_NAMED_ATTRS
>>ACE4_DELETE_CHILD
>>ACE4_READ_ATTRIBUTES
>>ACE4_WRITE_ATTRIBUTES
>>ACE4_DELETE
>>ACE4_READ_ACL
>>ACE4_WRITE_ACL
>>ACE4_WRITE_OWNER
>>ACE4_SYNCHRONIZE
>>
>>This means that if an ACE defines one of those access mask bits, the
>>access granted or denied will remain unchanged after a chmod.
>>    
>>
>
>I am afraid this is impossible: there is no such thing as being outside the 
>file access control mechanisms defined by POSIX. The reason is simple: POSIX 
>applications absolutely *must* be able to rely on POSIX semantics in order to 
>be able to keep the system secure.
>
>Let's assume that ACE4_WRITE_OWNER was indeed outside of the access control 
>mechanisms defined by POSIX as a counter example. A POSIX application does a 
>chmod to mode 0600 (rw-------) in order to restrict access to the file owner. 
>After that, the application can perfectly well write information that is 
>confidential to the owner into the file -- after all, only the owner will 
>have access, right?
>  
>
>Well, not quite, because an ACL might still grant ACE4_WRITE_OWNER to some 
>other user on the system. That other user could simply take over ownership of 
>the file, and do whatever he wants with it. Here we have it, a perfect 
>security hole; all POSIX applications potentially broken!
>
The owner of the file had taken *explicit* action to grant 
ACE4_WRITE_OWNER to another user on the system.  You say that it is a 
security hole if the user that was explicitly granted the ability to 
write owner is now able to do what they were told they could do?

>
>Therefore, there cannot be any file access control mechanisms which are 
>neither defined by POSIX, nor additional or alternate.
>
>By definition, pure POSIX applications have no idea which additional or 
>alternate file access control mechanisms a particular POSIX implementation 
>may define,
>


> so they cannot know about such sideband mechanisms, and they also 
>have no way of disabling them.
>
>Andreas
>
>  
>

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

[Andreas Gruenbacher]

On Friday 28 July 2006 08:32, Lisa Week wrote:
> >[...] We don't care about permissions that are not
> >granted, so we *could* only look at ALLOW ACEs, but this distinction is
> > not at all relevant.
>
> What?  I don't understand how you can say that "we don't care about
> permissions that are not granted".  We definitely care about permissions
> that are explicitly not granted.

What I mean is that when looking at which permissions go beyond additional 
file access control mechanisms, we don't need to consider DENY ACEs: DENY 
ACEs can only further restrict access, and so they are never alternate file 
access control mechanisms.

> Also, I believe it is relevant to make a distinction between ALLOW and
> DENY ACEs.  Here's why:
>
> The reasoning behind classifying those DENY ACEs as additional access
> control mechanisms are 1.) because they further restrict the permissions
> of users and groups (which is what additional does by definition) and
> 2.) we don't want them to have to be disabled upon chmod.  Try to think
> about it in a way that you have just set an explicit entry to deny
> certain permissions to a supplemental user or group.  It is important
> that those users or groups don't have their permissions elevated after
> chmod.

Yes.

> For example, if you have an ACL such as this:
>
> fred:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::DENY
> OWNER@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
> GROUP@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
> EVERYONE@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
>
>
> The mode would be 777.  User fred is denied the ability to read, write
> and execute because of the explicit deny ACE.  After chmod, fred should
> still not be able to read, write and execute.  That is the goal that we
> were trying to meet.

Yes.

> I realize that the mapping that you describe in section 4.4 of
> http://www.suse.de/~agruen/nfs4acl/mapping-nfsv4-acls-to-posix-00.html
> would also give us the capabilities that  I have described above.

Yes.

---

> With that said, I will go on to describe the capabilities that I feel
> the mapping in section 4.4 lacks.  The capabilities that it lacks is
> where the relevance of having those ALLOW ACEs that I described before
> be considered Alternate access control mechanisms comes in.
>
> The mapping in section 4.4 makes it impossible to do the following by
> *only* modifying the ACL.
>
> The mode of the file is 644 and you want to give fred the ability to
> read, write and execute.
>
> fred:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
> OWNER@:READ_DATA/WRITE_DATA/APPEND_DATA::ALLOW
> OWNER@:EXECUTE::DENY
> GROUP@:READ_DATA::ALLOW
> GROUP@:WRITE_DATA/APPEND_DATA/EXECUTE::DENY
> EVERYONE@:READ_DATA::ALLOW
> EVERYONE@:WRITE_DATA/APPEND_DATA/EXECUTE::DENY
>
> With the classification in 4.4, you can set that ACL, but it won't take
> effect until you also explicitly modify the file group class permissions
> (via a mask or whatever).

In Section 4.6. "Setting File Permissions, File Masks, and ACLs", 
http://www.suse.de/~agruen/nfs4acl/mapping-nfsv4-acls-to-posix-00.html reads:

[] When an ACL is set, the file masks may or may not be set in the same
[] operation. If they are not set in the same operation, each file mask shall
[] implicitly be set to the union of the mask bits of all ACEs that are in
[] the corresponding file class according to Table 1.
[]
[] When a file mask is set, either explicitly or implicitly by setting an ACL,
[] all permissions that active file mask bits correspond to in Table 2 shall
[] be set, and all other permissions shall be cleared.

So setting only the ACL will implicitly modify the file mode permission bits 
as needed. It is important to keep the masks in sync with the ACL, and to 
keep the file permission bits in sync with the masks. Without this behavior, 
setting permissions with ACLs would indeed be painful.

> The capability to set the type of ACL that is above was the goal when
> classifying ALLOW ACEs as Alternate security access control mechanisms.
> We can do this because as Alternate is defined, it can extend the
> permissions of a user.  Therefore, setting the ACL attribute is all that
> is needed for this to take effect.

I agree with you that setting an ACL is an explicit user action, and that this 
action may enable an alternate file access control mechanism. Whether the new 
ACL actually is an alternate file access control mechanism depends on which 
permissions the ACL allows: if it only allows permissions that map to Read, 
Write, and Execute and the file classes include those permissions, then the 
ACL does not actually go beyond additional file access control mechanisms. 
Otherwise, the ACL is an alternate file access control mechanism, and the 
alternate parts of it must be disabled upon chmod.

> ---
>
> I am trying to figure out why there has been such a disagreement here
> and perhaps this is another thing that needs to be cleared up.  What
> does the disabling of an alternate access control mechanism mean?
> Certainly it is not that we have to get rid of everything that is in an
> ALLOW ACE every time a chmod is done.

Indeed, we only have to disable what goes beyond an additional file access 
control mechanism.

> If you had the following ACL:
>
> fred:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
> OWNER@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
> GROUP@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
> EVERYONE@:READ_DATA/WRITE_DATA/APPEND_DATA/EXECUTE::ALLOW
>
> The mode would be 777.  Disabling can be meant that after the chmod, the
> user "fred" should not have more permissions that his respective class.
> So, after a chmod to 770, fred should still be allowed the ability to
> read, write and execute.  This is in how the permissions for fred are
> disabled.  They are being masked down to what the permissions of the
> file group class are.

Yes, exactly.

> >What counts is which access mask flags are equivalent to the POSIX Read,
> >Write, and Execute permissions, and which are not: those are the access
> > mask flags which may (sometimes) be used as additional access control
> > mechanisms.
>
> What do you mean by sometimes.

Consider your example ACL from above, and a chmod to 0750. In that case, we 
need to disable WRITE_DATA and APPEND_DATA for Fred and GROUP@, and 
READ_DATA, WRITE_DATA, APPEND_DATA, and EXECUTE for EVERYONE@. So when the 
File Group Class contains the Write permission, WRITE_DATA and APPEND_DATA 
are perfectly fine as an additional file access control mechanism. Removing 
Write from the File Group Class causes WRITE_DATA and APPEND_DATA to become 
Alternate, and we must make sure to disable them.

In mapping-nfsv4-acls-to-posix-00, I said the same thing like this:

[] Flags classified as additional are equivalent to or a subset of the
[] designated POSIX permission. If the file class of an ACE (see Section 4.1)
[] includes this permission, the ACE may grant this permission as part of an
[] additional file access control mechanism.

> >The other issue is which POSIX file class each ACE maps to. Let's assume
> > for now that we only know that OWNER@ maps to the File Owner Class to
> > keep this example short.
> >
> >Together with these two classifications, we can determine whether an ACE
> > is within the bounds of an additional file access control mechanism.
> > Let's look at the following ACE, and a file which has a file mode of 0740
> > (rwxr-----):
> >
> >  OWNER@:READ_DATA/APPEND_DATA/EXECUTE::ALLOW
> >
> >
> >The OWNER@ ACE maps to the File Owner Class. This means that as an
> > additional access control mechanism, the ACE may not grant more than
> > Read, Write, and Execute. The READ_DATA access mask flag is equivalent to
> > POSIX Read, the APPEND_DATA access mask flag is a subset of POSIX Write,
> > and the EXECUTE access mask flag is equivalent to POSIX Execute, so we
> > are fine.
> >
> >Now, let's assume that the user does a chmod to mode 0640 (rw-r-----). The
> >permissions of the File Owner Class now no longer cover the EXECUTE
> >permission. There are two options to fix this problem:
> >
> > 1. either accept that the ACE cannot be part of an additional file
> >    access control mechanism, or
> >
> > 2. disable the EXECUTE access mask flag, either temporarily or
> >    permanently, which gets us back into the bounds of additional file
> >    access control mechanisms.
> >
> >In case 1, the only choice that remains is that the ACE must be part of an
> >alternate file access control mechanism (see more on that below). POSIX
> >states that we must disable alternate file access control mechanisms upon
> >chmod and for new files, and they must only be re-enabled per explicit
> > user action. So the EXECUTE permission would be just gone until the user
> > explicitly re-enables it (with something other than a chmod). This would
> > render ACLs practically useless under POSIX.
>
> Why wouldn't the EXECUTE permission be able to be re-enabled with
> chmod?  Of course, it can.

Chmod must disable alternate file access control mechanisms as per the POSIX 
definitions, and so if we classified EXECUTE as alternate, a chmod could not 
re-enable it.

> If you are setting a mode of 740, that says that the owner can execute.

Yes. More precisely, it says the owner may be allowed to execute; additional 
file access control mechanisms may further restrict access, and deny the 
owner that permission.

> That is an explicit action and EXECUTE permission should be granted to the
> owner.

Ouch. Setting the mode to 740 is a chmod, right? Chmod is the one explicit 
action for which POSIX defines that it must disable alternate file access 
control mechanisms. The other explicit action that POSIX mentions is file 
creation, for which alternate file access control mechanisms must also be 
disabled. So please let's not mix things up here, and let's refrain from 
calling chmod an explicit action in this context.

> >In case 2, the ACE still remains within the bounds of additional file
> > access control mechanisms. If we disable EXECUTE only temporarily, then a
> > future chmod back to mode 0740 can simply re-enable EXECUTE, and we will
> > not have lost anything. (Remember, chmod does not disable additional file
> > access control mechanisms.)
> >
> >There are several possibilities how we can disable access mode flags
> >temporarily:
> >
> > 1. we could add an explicit DENY ACE before the ALLOW ACE that has
> >    the affected access mask flags disabled (this is the
> >    draft-ietf-nfsv4-acls-00 approach),
> >
> > 2. we could declare that all access mask flags which go beyond
> >    the corresponding File Class are automatically disabled, or
> >
> > 3. we could introduce file masks as I am proposing.
> >
> >The file masks have the advantage that the user can easily manually enable
> >more access mask flags in them. This would construe an explicit user
> > action as per POSIX. So depending on which flags the user enables, that
> > may amount to an additional or alternate file access control mechanism.
> > POSIX is perfectly fine with that, even for enabling flags such as
> > WRITE_OWNER. The only thing we must ensure is that alternate flags are
> > disabled upon chmod as well as for new files.
> >
> >>All other access mask bits listed below are outside of the access
> >>control mechanisms specified by POSIX and are therefore unclassified
> >>and unrestricted:
> >>ACE4_READ_NAMED_ATTRS
> >>ACE4_WRITE_NAMED_ATTRS
> >>ACE4_DELETE_CHILD
> >>ACE4_READ_ATTRIBUTES
> >>ACE4_WRITE_ATTRIBUTES
> >>ACE4_DELETE
> >>ACE4_READ_ACL
> >>ACE4_WRITE_ACL
> >>ACE4_WRITE_OWNER
> >>ACE4_SYNCHRONIZE
> >>
> >>This means that if an ACE defines one of those access mask bits, the
> >>access granted or denied will remain unchanged after a chmod.
> >
> >I am afraid this is impossible: there is no such thing as being outside
> > the file access control mechanisms defined by POSIX. The reason is
> > simple: POSIX applications absolutely *must* be able to rely on POSIX
> > semantics in order to be able to keep the system secure.
> >
> >Let's assume that ACE4_WRITE_OWNER was indeed outside of the access
> > control mechanisms defined by POSIX as a counter example. A POSIX
> > application does a chmod to mode 0600 (rw-------) in order to restrict
> > access to the file owner. After that, the application can perfectly well
> > write information that is confidential to the owner into the file --
> > after all, only the owner will have access, right?
> >
> >
> >Well, not quite, because an ACL might still grant ACE4_WRITE_OWNER to some
> >other user on the system. That other user could simply take over ownership
> > of the file, and do whatever he wants with it. Here we have it, a perfect
> > security hole; all POSIX applications potentially broken!
>
> The owner of the file had taken *explicit* action to grant ACE4_WRITE_OWNER
> to another user on the system. 

The owner takes explicit action to grant ACE4_WRITE_OWNER to another user on 
the system, which is beyond what POSIX defines. Then a POSIX process on 
behalf of the owner (or an admin) does a chmod to 0600. From all the POSIX 
process knows, the file can now only be accessed by the owner; there is 
nothing that keeps POSIX processes from making this assumption. To the POSIX 
process, chmod is a mechanism to enforce restricted access. Now if we let 
ACE4_WRITE_OWNER survive the chmod, we break this basic assumption, and 
nothing will guarantee that the intentions of the file owner combined with 
the valid assumptions of POSIX processes will lead to a secure system.

> You say that it is a security hole if the user that was explicitly granted
> the ability to write owner is now able to do what they were told they could
> do?

If that permission was granted by explicit user action without intervening 
chmod, no. After chmod, yes. It is not enough to look at the intentions of 
the file owner alone. We must also look at interactions with other actors 
that may have incomplete knowledge and different assumptions.

Andreas

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs