From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Kerrisk (man-pages)" Subject: richacl(7) man page review comments Date: Sun, 7 Feb 2016 17:35:46 +0100 Message-ID: <56B77262.7090107@gmail.com> References: <56B770B6.7040803@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <56B770B6.7040803-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andreas Gruenbacher Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, "J. Bruce Fields" , linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org, lkml , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API , Dave Chinner , Christoph Hellwig , Anna Schumaker , Trond Myklebust , Jeff Layton , Andreas Dilger List-Id: linux-api@vger.kernel.org Hi Andreas, I'll probably have quite a few more comments on this page as I get to understand RichACLs better. Here's some comments from an initial reading. So, an initial comment. It seems to me to that this page (but not setrichacl(1) and getrichacl(1)) should ultimately land in man-pages (just like acl(7)), since we're talking about a kernel feature. Make sense? > .\" > .\" Richacl Manual Pages > .\" > .\" Copyright (C) 2015 Red Hat, Inc. > .\" Written by Andreas Gruenbacher > .\" This is free documentation; you can redistribute it and/or > .\" modify it under the terms of the GNU General Public License as > .\" published by the Free Software Foundation; either version 2 of > .\" the License, or (at your option) any later version. > .\" > .\" The GNU General Public License's references to "object code" > .\" and "executables" are to be interpreted as the output of any > .\" document formatting or typesetting system, including > .\" intermediate and printed output. > .\" > .\" This manual is distributed in the hope that it will be useful, > .\" but WITHOUT ANY WARRANTY; without even the implied warranty of > .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > .\" GNU General Public License for more details. > .\" > .\" You should have received a copy of the GNU General Public > .\" License along with this manual. If not, see > .\" . > .\" > .de URL > \\$2 \(laURL: \\$1 \(ra\\$3 > .. > .if \n[.g] .mso www.tmac > .TH RICHACL 7 2015-09-01 "Linux" "Rich Access Control Lists" > .SH NAME > richacl \- Rich Access Control Lists > .SH DESCRIPTION > Rich Access Control Lists (richacls) are an extension of the POSIX fi= le =46or what it's worth, I think it would be worthwhile to start with a consistent abbreviation comment here (and use it throughout all of th= e man pages): "RichACL" (or "richACL"), rather than "richacl"; that seems more consistent with the traditional abbreviation "ACL". > permission model to support Make this: permission mode (see =2EBR acl (7)) to support > .URL https://tools.ietf.org/rfc/rfc5661.txt "NFSv4 Access Control Lis= ts" > on local and remote-mounted filesystems. >=20 > Richacls support file masks which allow to apply a file mode to an ex= isting s/which allow to apply/which can be used to apply/ > NFSv4 ACL without destructive side effects: the file mode determines = the values > of the file masks; the file masks restrict the permissions granted by= the NFSv4 > ACL. When a less restrictive file mode is applied later, the file ma= sks become > less restrictive, and more of the original permissions can become eff= ective. >=20 > A richacl can always be translated into an equivalent NFSv4 ACL which= grants > the same permissions. >=20 > Richacls can be enabled on supported filesystems. This disables POSIX= Access > Control Lists; the two ACL models will not coexist on the same filesy= stem. s/will not/can not/ ? >=20 > When used on a filesystem that does not support richacls, the getrich= acl and Use =2EBR getrichacl (1) for cross-references. > setrichacl utilities will operate on the file permission bits instead= : > getrichacl will display the file permission bits as a richacl; when a= richacl Use =2EBR getrichacl (1) for cross-references. > is set with setrichacl which can be represented exactly by the file p= ermission Use =2EBR setrichacl (1) for cross-references. > bits, setrichacl will set the file permission bits instead. Use =2EBR setrichacl (1) for cross-references. Here, I think it would be helpful to add a sentence: "An attempt to set a richacl that cannot be represented exactly by the file permission bits results in an error." (If that sentence is correct, of course.) >=20 > .SH STRUCTURE OF RICHACLS =46or all of the "nonstandard" (see man-pages(7)) ".SH" sections here, = I'd be inclined to switch to using ".SS" subsections. There are downsides t= o multiple nonstandard section headings (e.g., automated TOCs for Section headings become clumsy and long), and I don't think your use of =2ESH vs .SS really helps much to structure the information in this pag= e. >=20 > Richacls consist of a number of ACL entries, three file masks, and so= me flags. s/some flags./some flags specifying attributes of the ACL as whole (by contrast with the per-ACL-entry flags described below)./ > Each of the ACL entries allows or denies some permissions to a partic= ular user, > group, or special entity. Each acl entry consists of: s/acl// > .IP \(bu 4 > The user (with prefix s/The user/A tag which specifies the user/ (Is "tag" the right word? In any case, what would helpful to have here is the generic term for this component of the ACL.) > .B user: > or > .BR u: ), > group (with prefix > .B group: > or > .BR g: ), > or special identifier the entry applies to. Special > identifiers can be the file owner > .RB ( owner@ ), > the owning group > .RB ( group@ ), > or everyone > .RB ( everyone@ ). > .IP \(bu > A set of permissions the entry allows or denies. > .IP \(bu > A set of flags that indicate whether the user or group identifier is = mapped or > unmapped, and whether the entry has been and can be inherited. > .IP \(bu 4 > A field indicating whether the entry allows or denies access. > .PP > The owner, group, and other file masks further control which permissi= ons the > ACL grants, subject to the > .B masked > .RB ( m ) > and > .B write_through > .RB ( w ) > ACL flags. >=20 > Note that entries with the identifier > .B everyone@ > apply to all processes, whereas the \(lqother\(rq file permissions an= d > \(lqother\(rq entries in POSIX ACLs apply to all processes which are = not the > owner, are not in the owning group, and do not match a user or group = mentioned > in the acl. s/acl/ACL/ > Richacls do not have separate \(lqaccess\(rq ACLs that define the acc= ess > permissions and \(lqdefault\(rq ACLs that define the inheritable perm= issions as > POSIX ACLs. I'd restructure the preceding sentence as: "Unlike POSIX ACLs, richacls do not.... that define the inheritable permissions." > Instead, whether an ACL entry is effective during access checks > and/or inheritable is determined by the ACL entry flags. >=20 > .SS ACL Flags I'd use lower case in the above for all words except the first. (That's the convention in man-pages.) >=20 > The following flags on ACLs are defined: >=20 > .RS 4 > .HP 4 s/4/8/ in the preceding two lines. I think more indentation would make this (and the similar lists below) more readable. > .B masked > .RB ( m ): I'd write each of these list entries starting here, and below, in the form: =2EBR masked "\ (" m ): This form is a little easier to read in the source, and it forces just a single space before the "(", which looks a little better, I find. > When set, the file masks define upper limits on the permissions the A= CL may > grant. > .HP > .B write_through > .RB ( w ): > When this flag and the masked flag are both set, the owner and other = file masks =2EB masked > define the actual permissions granted to the file owner and to others= instead > of an upper limit. > .HP > .B auto_inherit > .RB ( a ): > Automatic Inheritance is enabled for the file the ACL is > attached to. See > .IR "Automatic Inheritance" . > .HP > .B protected > .RB ( p ): > The ACL is protected from modification by Automatic > Inheritance. > .HP > .B defaulted > .RB ( d ): > The ACL has been assigned by default. Automatic Inheritance should co= mpletely > replace the ACL. > .RE >=20 > .SS ACL Entry Flags >=20 > The following flags on ACL entries are defined: >=20 > .RS 4 > .HP 4 s/4/8/ in the preceding two lines. > .B file_inherit > .RB ( f ): > The entry is inheritable for files. > .HP > .B dir_inherit > .RB ( d ): > The entry is inheritable for directories. > .HP > .B no_propagate > .RB ( n ): > Inheritance stops at the next subdirectory level. > .HP > .B inherit_only > .RB ( i ): > The entry defines inheritable permissions only and is ignored for acc= ess > checking. > .HP > .B inherited > .RB ( a ): > The entry has been automatically inherited from the parent directory;= the > ACL's auto_inherit Use =2EB auto_inherit > .RB ( a ) > flag should be on. > .HP > .B unmapped > .RB ( u ): > The user or group identifier is a textual string and has no mapping t= o a > numeric user or group identifier. So here, I think there should be a sentence that explains how a meaning is attached to the strings? Is this for NFS, for Windows, for something else? > .RE >=20 > .SS Permissions >=20 > The following permissions are defined for richacl entries and for the= three > file masks: >=20 > .RS 4 > .HP 4 s/4/8/ in the preceding two lines. > .B read_data > / > .B list_directory > .RB ( r ): Replace the preceding four lines by =2EBR read_data / list_directory "\ (" r ) and do similar for the next two list entried below. Note that "\ (" will force just a singlke space before the "(". > Read the data of a file. > List the contents of a directory. In the above list entry, and the next two, I find the layout ("xxx/yyy = (z)") confusing. A closer reading indicates that in each case, the "xxx" applies for files and he "yyy" is for directories. But I think the text could make this point a little easier to grasp. In each of these three list entries this could be done something lke the following: "For a file: read the data of the file. For a directory: list the contents of the directory." By the way, can the terms "read_data" and "list_directory" be used interchangeably? That is, can you employ (say) "read_data" when setting an ACL entry for a directory? (I'm assuming the answer is "yes".) If the terms are just interchangeable synonyms, perhas it's worth making that point explicitly in the text. > .HP > .B write_data > / > .B add_file > .RB ( w ): > Modify the data of a file. Add a new file in a directory. See above comment re file/directory. > .HP > .B append_data > / > .B add_subdirectory > .RB ( p ): > Open a file in append mode. Create a subdirectory in a directory. So, in other words, if append mode is denied, then the file can be opened for writing (contingent on write permission being granted), but can't be opened with O_APPEND? Is that correct? This point needs to be made clearer. > .HP > .B execute > .RB ( x ): > Execute a file. Traverse / search a directory. See above comment re file/directory. > .HP > .B delete_child > .RB ( d ): > Delete a file or directory within a directory. > .HP > .B delete > .RB ( D ): > Delete the file or directory. > .HP > .B read_attributes > .RB ( a ): > Read basic attributes of a file or directory. What are "attributes" in this context? Does this mean stat(2)? Make thi= s explicit. > This permission is always implicitly granted. > .HP > .B write_attributes > .RB ( A ): > Change the times associated with a file or directory to an arbitrary = value. > This permission is always implicitly granted to the file owner. > .HP > .B read_acl > .RB ( c ): > Read the ACL of a file or directory. This permission is always > implicitly granted. > .HP > .B write_acl > .RB ( C ): > Change the ACL or file mode of a file or directory. > .HP > .B write_owner > .RB ( o ): > Take ownership of a file or directory. Change the owning group of a = file or > directory to a group of which the calling process is a member. > .HP > .B read_named_attrs > .RB ( R ), > .B write_named_attrs > .RB ( W ), > .B synchronize > .RB ( S ), > .B write_retention > .RB ( e ), > .B write_retention_hold > .RB ( E ): > These permissions can be stored, but do not have a local meaning. So, I thenk that a sentence here should explain why these permissions exist. Is if for future extension, because they are meaningful in NFS, or something else? > .RE >=20 > .SH TEXT FORM >=20 > The common textual representation of richacl consists of the colon se= parated s/richacl/richacls/ (or, "RichACLs"/"richACLs") s/colon separated/colon-separated/ > fields of the the acl flags, file masks, and acl entries in the follo= wing s/acl/ACL/ (*2) > format: > .TP > \fBflags:\fR\fIacl_flags\fR > The ACL flags. > .TP > \fBowner:\fR\fIperm\fR\fB::mask\fR, \fBgroup:\fR\fIperm\fR\fB::mask\f= R, \fBother:\fR\fIperm\fR\fB::mask\fR > The file masks and their permissions. > .TP > \fIwho\fR\fB:\fR\fIperm\fR\fB:\fR\fIflags\fR\fB:allow\fR, \fIwho\fR\f= B:\fR\fIperm\fR\fB:\fR\fIflags\fR\fB:deny\fR > For each ACL entry, who the entry applies to, the permissions of the = entry, the > entry flags, and whether the entry allows or denies permissions. The= who field has s/who/\\fIwho\\fP/ > no prefix for special identifiers, a > .B user: > or > .B u: > prefix for regular users, and a > .B group: > or > .B g: > prefix for regular groups. > .PP > The entries are comma, whitespace or newline separated. s/whitespace/whitespace,/ >=20 > Flags and permissions have single-letter as well as long forms as lis= ted under s/forms/forms,/ > .IR "ACL Flags" , > .IR "ACL Entry Flags" , > and > .IR Permissions . If you follow my suggestion about capitalization in the ".SS" entries, you'll need to change the capitalization in the above phrases. > When the single-letter forms are used, the flags or permissions are > concatenated. When the long forms are used, the flags or permissions = are > separated by slashes. To align permissions or flags vertically, dash= es can be > use for padding. s/use/used/ >=20 > .SH SETTING AND MODIFYING FILE PERMISSIONS > The access permissions for a file can either be set by assigning an a= ccess > control list (setrichacl) or by changing the file mode permission bit= s (chmod). Use =2ERB ( setrichacl (1)) for cross-reference. Use =2ERB ( chmod (1)). > In addition, a file can inherit an ACL from its parent > directory at create time; the inherited ACL is then further s/create/creation/ > restricted by the creating system call's mode parameter (see the crea= t(2) > manual page). creat(2) is pretty much history. I suggest writing (as given to =2EBR open (2), =2EBR mkdir (2), and similar). And here, I think we need a statement about whether the process umask has an effect or not... >=20 > .SS Assigning An Access Control List > When assigning an ACL to a file, unless explicitly specified, the own= er, group, > and other file masks will be computed from the ACL entries as describ= ed in > section > .IR "COMPUTING THE MAXIMUM FILE MASKS" . > The owner, group, and other file mode permission bits are then each s= et from > the owner, group, and other file mask as follows: > .IP \(bu 4 > If the file mask includes the > .B r > permission, the read > file mode permission bit will be set. > .IP \(bu > If the file mask includes the > .B w > or > .B p > permission, the write file mode permission bit will be set. > .IP \(bu > If the file mask includes the > .B x > permission, the execute file mode permission bit will be set. > .PP > If the ACL can be represented exactly by the file mode > permission bits, the file permission bits are set to match the access= control > list and the ACL is not stored. (When the reverse happens and s/and/and the/ > ACL of a file is requested which doesn't have an explicit > ACL, the file mode permission bits are converted into an > equivalent richacl.) >=20 > .SS Changing The File Mode Permission Bits I'd use lower case in the above for all words except the first > When changing the file mode permission bits with chmod(2), the owner,= group, =2EBR chmod (2) > and other file permission bits are set to the permission bits in the = new mode, > and the file masks each are set based on the new mode bits as follows= : > .IP \(bu 4 > If the read bit in a set of permissions is set, the > .B r > permission in the corresponding file mask will be set. > .IP \(bu > If the write bit in a set of permissions is set, the > .B w > and > .B p > permissions in the corresponding file mask will be set. > .IP \(bu > If the execute bit in a set of permissions is set, the > .B x > permission in the corresponding file mask will be set. > .PP > In addition, the > .B masked > and > .B write_through > ACL flags are set. This has the > effect of limiting the permissions granted by the ACL to the file mod= e > permission bits; in addition, the owner is granted the owner mode bit= s and > others are granted the other mode bits. If the > .B auto_inherit > flag is set, the > .B protected > flag is also set to prevent the Automatic Inheritance algorithm from = modifying > the ACL. >=20 > .SS Permissions At File Create Time s/File Create/file-creation/ I'd use lower case in the above for all words except the first > When a directory has inheritable ACL entries, the following > happens when a file or directory is created inside that directory: > .RS 4 > .IP 1. 4 > A file created inside that directory will inherit all entries with th= e s/all entries with/all of the directories entries that/ > .B file_inherit > flag set, and all inheritance-related flags in the inherited entries = will be > cleared. >=20 > A subdirectory will inherit all entries with the > .B file_inherit > or > .B dir_inherit > flag set. Entries whose > .B no_propagate > flag is set will have all inheritance-related flags cleared. Entries= whose > .B no_propagate > and > .B dir_inherit > flags are not set and whose > .B file_inherit > is set will have their > .B inherit_only > flag set. > .IP 2. > If the parent directory's ACL has the > .B auto_inherit > flag set, the inherited ACL will have its > .B auto_inherit > flag set, and all entries will have their > .B inherited > flag set. > .IP 3. > The three file masks are computed from the inherited ACL as described= in > section > .IR "COMPUTING THE MAXIMUM FILE MASKS" . > .IP 4. > The three sets of permissions for the owner, the group, and for other= s in > the mode parameter of the creating system call are converted into set= s of > richacl permissions as described in section s/in/in the/ > .IR "Changing The File Mode Permission Bits" . > Any richacl permissions not included in those sets are > removed from the owner, group, and other file masks. The file mode pe= rmission > bits are then computed from the file masks as described in section s/in/in the/ > .IR "Assigning An Access Control List" . > .IP 5. > The > .B masked > ACL flag is set. The > .B write_through > ACL flag remains cleared. In addition, if the > .B auto_inherit > flag of the inherited ACL is set, the > .B protected > flag is also set to prevent the Automatic Inheritance algorithm from = modifying > the ACL. > .RE > .PP > When a directory does not have inheritable ACL entries, files > and directories created inside that directory will not be assigned ac= cess > control lists and the file mode permission bits will be set to (mode\= &\ > ~umask). will be set to (mode & umask) where =2EI mode is the permission mode argument of the relevant system call and =2EI umask is the process umask (see =2EBR umask (2)). >=20 > .SS Automatic Inheritance I'd use lower case in the above for all words except the first > Automatic Inheritance allows permission changes to propagate from a d= irectory > to files and subdirectories inside that directory, recursively. Carr= ying out > this propagation of permissions is the responsibility of the process = changing > the directory permissions (usually, setrichacl(1)). I'm confused by the previous sentence. the feature is labeled "Automati= c Inheritance", implying that the user/process need do nothing. The next sentence says "propagation ... is the responsibility of the process". These two points seem contradictory. I think something more needs to be said here. >=20 > A significant limitation is that this mechanism works only as long as= files > are created without explicitly specifying the file permissions to use= =2E The > standard system calls for creating files an directories (creat(2), op= en(2), > mkdir(2), mkfifo(2), mknod(2)) all have mandatory mode parameters whi= ch define =46ormat that system call list as =2ERB ( creat (2), =2EBR open (2), =2EBR mkdir (2), =2EBR mknod (2)) Note that I removed mkfifo(): it's a library functionlayered on mkonod(2). > the maximum allowed permissions of the new files. To take account of = this > restriction, the > .B protected > ACL flag must be set if the > .B inherited > flag is set. This effectively disables Automatic Inheritance for that > particular file. >=20 > Automatic Inheritance still remains useful for network protocols like= NFSv4 and > SMB, which both support creating files and directories without defini= ng which > permissions: they can implement those operations by using the standar= d system > calls and by then undoing the effect of applying the mode parameters. >=20 > When the ACL of a directory is changed, the following should Why "should"? > happen for each entry inside that directory (for each \(lqchild\(rq): Make the preceding line: happen for each entry (\(lqchild\(rq) inside that directory: > .IP 1. 4 > If the entry is a symblic link, skip the child. > .IP 2. > If the > .B auto_inherit > flag of the entry's ACL is not set or the > .B protected > flag is set, skip the child. > .IP 3. > With the child's ACL: > .RS 4 > .IP 1. 4 s/1./a)/ (i.e., use a different labeling scheme for the sublist) > If the > .B defaulted > flag is set, replace the ACL with an empty ACL > with the > .B auto_inherit > flag set. > .IP 2. s/2./b)/ > Delete all entries which have the > .B inherited > flag set. > .IP 3. s/3./c)/ > Append all entries inherited from the parent directory according to s= tep 1 of > the algorithm described under > .IR "Permissions At File Create Time". > Set the > .B inherited > flag of each of these entries. > .IP 4. s/4./d)/ > Recompute the file masks. > .RE > .IP 4. > If the child is a directory, recursively apply this algorithm. >=20 > .SH ACCESS CHECK ALGORITHM >=20 > When a process requests a particular kind of access to a file defined= by a set s/defined/protected/ (?) > of richacl permissions, the following algorithm determines if the acc= ess is s/if/whether/ > granted or denied: >=20 > .IP 1. 4 > If the > .B masked > ACL flag is set, then: > .RS 4 > .IP 1. 4 s/1./a)/ Use a different numbering scheme for sublists. > if the s/if/If/ > .B write_through > ACL flag is set, then: > .RS 4 > .IP \(bu 4 > if the requesting process is the file owner, then access is granted i= f the s/if/If/ > owner mask includes the requested permissions, and is otherwise denie= d. > .IP \(bu > if the requesting process is not the file owner, is not in the owning= group, s/if/If/ > and no ACL entries other than > .B everyone@ > match the process, then access is granted if the other mask includes = the > requested permissions, and is otherwise denied. > .RE > .IP 2. s/2./b)/ > if any of the following is true: s/if/If/ > .RS 4 > .IP \(bu 4 > the requesting process is the file owner and the owner mask does no i= nclude all s/no /not / > requested permissions, > .IP \(bu 4 > the requesting process is not the file owner and it is in the owning = group or > matches any ACL entries other than > .BR everyone@ , > and the group mask does no include all requested permissions, > .IP \(bu 4 > the requesting process is not the file owner, not in the owning group= , it > matches no ACL entries other than > .BR everyone@ , > and the other mask does no include all requested permissions, > .PP > then access is denied. > .RE > .RE > .IP 2. > Set the remaining permissions to the requested permissions. Go throu= gh all ACL > entries. For each entry: > .RS 4 > .IP 1. 4 s/1./a)/ Use a different numbering scheme for sublists. > if the > .B inherit_only > or > .B unmapped > flags are set, continue with the next ACL entry. > .IP 2. s/2./b)/ > if any of the following is true: > .RS 4 > .IP \(bu 4 > the entry's identifier is > .B owner@ > and the requesting process is the file owner, > .IP \(bu > the entry's identifier is > .B group@ > and the requesting process is in the owning group, > .IP \(bu > the entry's identifier is a user and the requesting process is owned = by that > user, > .IP \(bu > the entry's identifier is a group and the requesting process is a mem= ber in > that group, > .IP \(bu > the entry's identifier is > .BR everyone@ , > .PP > the entry matches the process; proceed. Otherwise, continue with the = next ACL s/proceed/proceed to the next step/ (?) > entry. > .RE > .IP 3. s/3./c)/ > If the entry denies any of the remaining permissions, access is denie= d. > .IP 4. s/4./d)/ > If the entry allows any of the remaining permissions, then: > .RS 4 > .IP \(bu 4 > if the > .B masked > ACL flag is set and the entry's identifier is not > .B owner@ > or > .BR everyone@ > or is a user entry matching the file owner, remove all permissions fr= om the > remaining permissions which are both allowed by the entry and include= d in the > group mask, > .IP \(bu > otherwise, remove all permissions from the remaining permissions wich= are > allowed by the entry. > .RE > .RE > .IP 3. > If there are no more remaining permissions, access is allowed. Otherw= ise, > access is denied. >=20 > .SH COMPUTING THE MAXIMUM FILE MASKS > When setting an ACL and no file masks have been explicitly specified = and when > inheriting an ACL from the parent directory, the following algorithm = is used > for computing the file masks: >=20 > .IP 1. 4 > Clear the owner, group, and other file masks. Remember which permissi= ons have > already been processed (initially, the empty set). > .IP 2. > For each ACL entry: > .RS 4 > .IP \(bu 4 > If the > .B inherit_only > flag is set, skip the entry. > .IP \(bu 4 > Otherwise, compute which permissions the entry allows or denies that = have not > been processed yet (the remaining permissions). > .IP \(bu > If the entry is an > .B owner@ > entry, add the remaining permissions to the owner mask for > .B allow > entries, and remove the remaining permissions from the owner mask for > .B deny > entries. > .IP \(bu > Otherwise, if the entry is an > .B everyone@ > entry, proceed as with > .B owner@ > entries but add or remove the remaining permissions from the owner, g= roup, and > other file masks. > .IP \(bu > Otherwise, proceed as with > .B owner@ > entries but add or remove the remaining permissions from the owner an= d group > file masks. > .IP \(bu > Add the entry's permissions to the processed permissions. > .RE > .PP > The resulting file masks represent the ACL as closely as possible. Wi= th these > file masks, if the > .B masked > ACL flag is set, the effective permissions still stay the same. This page is in *desperate* need of *multiple* examples, starting simpl= e, and building up in complexity, with walkthogh text explaining how the permisssions are interpreted and how the masks are generated. Having read the page multiple times (and having little knowledge of NFS ACLs), I'm still struggling to put all the pieces together. Probably some examples that relate to an NFS context would also be helpful. > .\" .SH BUGS > .SH AUTHOR > Written by Andreas Gr=C3=BCnbacher . >=20 > Please send your bug reports, suggested features and comments to the = above address. >=20 > .SH CONFORMING TO > Rich Access Control Lists are Linux-specific. > .SH SEE ALSO > .BR chmod (1), > .BR getrichacl (1), > .BR ls (1), > .BR setrichacl (1) > .BR stat (2), > .BR umask (2), > .BR acl (7) > .\" librichacl Cheers, Michael --=20 Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com ([74.125.82.42]:35495 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750980AbcBGQfw (ORCPT ); Sun, 7 Feb 2016 11:35:52 -0500 Subject: richacl(7) man page review comments To: Andreas Gruenbacher References: <56B770B6.7040803@gmail.com> Cc: mtk.manpages@gmail.com, "J. Bruce Fields" , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, lkml , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, Linux API , Dave Chinner , Christoph Hellwig , Anna Schumaker , Trond Myklebust , Jeff Layton , Andreas Dilger From: "Michael Kerrisk (man-pages)" Message-ID: <56B77262.7090107@gmail.com> Date: Sun, 7 Feb 2016 17:35:46 +0100 MIME-Version: 1.0 In-Reply-To: <56B770B6.7040803@gmail.com> Content-Type: text/plain; charset=utf-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: Hi Andreas, I'll probably have quite a few more comments on this page as I get to understand RichACLs better. Here's some comments from an initial reading. So, an initial comment. It seems to me to that this page (but not setrichacl(1) and getrichacl(1)) should ultimately land in man-pages (just like acl(7)), since we're talking about a kernel feature. Make sense? > .\" > .\" Richacl Manual Pages > .\" > .\" Copyright (C) 2015 Red Hat, Inc. > .\" Written by Andreas Gruenbacher > .\" This is free documentation; you can redistribute it and/or > .\" modify it under the terms of the GNU General Public License as > .\" published by the Free Software Foundation; either version 2 of > .\" the License, or (at your option) any later version. > .\" > .\" The GNU General Public License's references to "object code" > .\" and "executables" are to be interpreted as the output of any > .\" document formatting or typesetting system, including > .\" intermediate and printed output. > .\" > .\" This manual is distributed in the hope that it will be useful, > .\" but WITHOUT ANY WARRANTY; without even the implied warranty of > .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > .\" GNU General Public License for more details. > .\" > .\" You should have received a copy of the GNU General Public > .\" License along with this manual. If not, see > .\" . > .\" > .de URL > \\$2 \(laURL: \\$1 \(ra\\$3 > .. > .if \n[.g] .mso www.tmac > .TH RICHACL 7 2015-09-01 "Linux" "Rich Access Control Lists" > .SH NAME > richacl \- Rich Access Control Lists > .SH DESCRIPTION > Rich Access Control Lists (richacls) are an extension of the POSIX file For what it's worth, I think it would be worthwhile to start with a consistent abbreviation comment here (and use it throughout all of the man pages): "RichACL" (or "richACL"), rather than "richacl"; that seems more consistent with the traditional abbreviation "ACL". > permission model to support Make this: permission mode (see .BR acl (7)) to support > .URL https://tools.ietf.org/rfc/rfc5661.txt "NFSv4 Access Control Lists" > on local and remote-mounted filesystems. > > Richacls support file masks which allow to apply a file mode to an existing s/which allow to apply/which can be used to apply/ > NFSv4 ACL without destructive side effects: the file mode determines the values > of the file masks; the file masks restrict the permissions granted by the NFSv4 > ACL. When a less restrictive file mode is applied later, the file masks become > less restrictive, and more of the original permissions can become effective. > > A richacl can always be translated into an equivalent NFSv4 ACL which grants > the same permissions. > > Richacls can be enabled on supported filesystems. This disables POSIX Access > Control Lists; the two ACL models will not coexist on the same filesystem. s/will not/can not/ ? > > When used on a filesystem that does not support richacls, the getrichacl and Use .BR getrichacl (1) for cross-references. > setrichacl utilities will operate on the file permission bits instead: > getrichacl will display the file permission bits as a richacl; when a richacl Use .BR getrichacl (1) for cross-references. > is set with setrichacl which can be represented exactly by the file permission Use .BR setrichacl (1) for cross-references. > bits, setrichacl will set the file permission bits instead. Use .BR setrichacl (1) for cross-references. Here, I think it would be helpful to add a sentence: "An attempt to set a richacl that cannot be represented exactly by the file permission bits results in an error." (If that sentence is correct, of course.) > > .SH STRUCTURE OF RICHACLS For all of the "nonstandard" (see man-pages(7)) ".SH" sections here, I'd be inclined to switch to using ".SS" subsections. There are downsides to multiple nonstandard section headings (e.g., automated TOCs for Section headings become clumsy and long), and I don't think your use of .SH vs .SS really helps much to structure the information in this page. > > Richacls consist of a number of ACL entries, three file masks, and some flags. s/some flags./some flags specifying attributes of the ACL as whole (by contrast with the per-ACL-entry flags described below)./ > Each of the ACL entries allows or denies some permissions to a particular user, > group, or special entity. Each acl entry consists of: s/acl// > .IP \(bu 4 > The user (with prefix s/The user/A tag which specifies the user/ (Is "tag" the right word? In any case, what would helpful to have here is the generic term for this component of the ACL.) > .B user: > or > .BR u: ), > group (with prefix > .B group: > or > .BR g: ), > or special identifier the entry applies to. Special > identifiers can be the file owner > .RB ( owner@ ), > the owning group > .RB ( group@ ), > or everyone > .RB ( everyone@ ). > .IP \(bu > A set of permissions the entry allows or denies. > .IP \(bu > A set of flags that indicate whether the user or group identifier is mapped or > unmapped, and whether the entry has been and can be inherited. > .IP \(bu 4 > A field indicating whether the entry allows or denies access. > .PP > The owner, group, and other file masks further control which permissions the > ACL grants, subject to the > .B masked > .RB ( m ) > and > .B write_through > .RB ( w ) > ACL flags. > > Note that entries with the identifier > .B everyone@ > apply to all processes, whereas the \(lqother\(rq file permissions and > \(lqother\(rq entries in POSIX ACLs apply to all processes which are not the > owner, are not in the owning group, and do not match a user or group mentioned > in the acl. s/acl/ACL/ > Richacls do not have separate \(lqaccess\(rq ACLs that define the access > permissions and \(lqdefault\(rq ACLs that define the inheritable permissions as > POSIX ACLs. I'd restructure the preceding sentence as: "Unlike POSIX ACLs, richacls do not.... that define the inheritable permissions." > Instead, whether an ACL entry is effective during access checks > and/or inheritable is determined by the ACL entry flags. > > .SS ACL Flags I'd use lower case in the above for all words except the first. (That's the convention in man-pages.) > > The following flags on ACLs are defined: > > .RS 4 > .HP 4 s/4/8/ in the preceding two lines. I think more indentation would make this (and the similar lists below) more readable. > .B masked > .RB ( m ): I'd write each of these list entries starting here, and below, in the form: .BR masked "\ (" m ): This form is a little easier to read in the source, and it forces just a single space before the "(", which looks a little better, I find. > When set, the file masks define upper limits on the permissions the ACL may > grant. > .HP > .B write_through > .RB ( w ): > When this flag and the masked flag are both set, the owner and other file masks .B masked > define the actual permissions granted to the file owner and to others instead > of an upper limit. > .HP > .B auto_inherit > .RB ( a ): > Automatic Inheritance is enabled for the file the ACL is > attached to. See > .IR "Automatic Inheritance" . > .HP > .B protected > .RB ( p ): > The ACL is protected from modification by Automatic > Inheritance. > .HP > .B defaulted > .RB ( d ): > The ACL has been assigned by default. Automatic Inheritance should completely > replace the ACL. > .RE > > .SS ACL Entry Flags > > The following flags on ACL entries are defined: > > .RS 4 > .HP 4 s/4/8/ in the preceding two lines. > .B file_inherit > .RB ( f ): > The entry is inheritable for files. > .HP > .B dir_inherit > .RB ( d ): > The entry is inheritable for directories. > .HP > .B no_propagate > .RB ( n ): > Inheritance stops at the next subdirectory level. > .HP > .B inherit_only > .RB ( i ): > The entry defines inheritable permissions only and is ignored for access > checking. > .HP > .B inherited > .RB ( a ): > The entry has been automatically inherited from the parent directory; the > ACL's auto_inherit Use .B auto_inherit > .RB ( a ) > flag should be on. > .HP > .B unmapped > .RB ( u ): > The user or group identifier is a textual string and has no mapping to a > numeric user or group identifier. So here, I think there should be a sentence that explains how a meaning is attached to the strings? Is this for NFS, for Windows, for something else? > .RE > > .SS Permissions > > The following permissions are defined for richacl entries and for the three > file masks: > > .RS 4 > .HP 4 s/4/8/ in the preceding two lines. > .B read_data > / > .B list_directory > .RB ( r ): Replace the preceding four lines by .BR read_data / list_directory "\ (" r ) and do similar for the next two list entried below. Note that "\ (" will force just a singlke space before the "(". > Read the data of a file. > List the contents of a directory. In the above list entry, and the next two, I find the layout ("xxx/yyy (z)") confusing. A closer reading indicates that in each case, the "xxx" applies for files and he "yyy" is for directories. But I think the text could make this point a little easier to grasp. In each of these three list entries this could be done something lke the following: "For a file: read the data of the file. For a directory: list the contents of the directory." By the way, can the terms "read_data" and "list_directory" be used interchangeably? That is, can you employ (say) "read_data" when setting an ACL entry for a directory? (I'm assuming the answer is "yes".) If the terms are just interchangeable synonyms, perhas it's worth making that point explicitly in the text. > .HP > .B write_data > / > .B add_file > .RB ( w ): > Modify the data of a file. Add a new file in a directory. See above comment re file/directory. > .HP > .B append_data > / > .B add_subdirectory > .RB ( p ): > Open a file in append mode. Create a subdirectory in a directory. So, in other words, if append mode is denied, then the file can be opened for writing (contingent on write permission being granted), but can't be opened with O_APPEND? Is that correct? This point needs to be made clearer. > .HP > .B execute > .RB ( x ): > Execute a file. Traverse / search a directory. See above comment re file/directory. > .HP > .B delete_child > .RB ( d ): > Delete a file or directory within a directory. > .HP > .B delete > .RB ( D ): > Delete the file or directory. > .HP > .B read_attributes > .RB ( a ): > Read basic attributes of a file or directory. What are "attributes" in this context? Does this mean stat(2)? Make this explicit. > This permission is always implicitly granted. > .HP > .B write_attributes > .RB ( A ): > Change the times associated with a file or directory to an arbitrary value. > This permission is always implicitly granted to the file owner. > .HP > .B read_acl > .RB ( c ): > Read the ACL of a file or directory. This permission is always > implicitly granted. > .HP > .B write_acl > .RB ( C ): > Change the ACL or file mode of a file or directory. > .HP > .B write_owner > .RB ( o ): > Take ownership of a file or directory. Change the owning group of a file or > directory to a group of which the calling process is a member. > .HP > .B read_named_attrs > .RB ( R ), > .B write_named_attrs > .RB ( W ), > .B synchronize > .RB ( S ), > .B write_retention > .RB ( e ), > .B write_retention_hold > .RB ( E ): > These permissions can be stored, but do not have a local meaning. So, I thenk that a sentence here should explain why these permissions exist. Is if for future extension, because they are meaningful in NFS, or something else? > .RE > > .SH TEXT FORM > > The common textual representation of richacl consists of the colon separated s/richacl/richacls/ (or, "RichACLs"/"richACLs") s/colon separated/colon-separated/ > fields of the the acl flags, file masks, and acl entries in the following s/acl/ACL/ (*2) > format: > .TP > \fBflags:\fR\fIacl_flags\fR > The ACL flags. > .TP > \fBowner:\fR\fIperm\fR\fB::mask\fR, \fBgroup:\fR\fIperm\fR\fB::mask\fR, \fBother:\fR\fIperm\fR\fB::mask\fR > The file masks and their permissions. > .TP > \fIwho\fR\fB:\fR\fIperm\fR\fB:\fR\fIflags\fR\fB:allow\fR, \fIwho\fR\fB:\fR\fIperm\fR\fB:\fR\fIflags\fR\fB:deny\fR > For each ACL entry, who the entry applies to, the permissions of the entry, the > entry flags, and whether the entry allows or denies permissions. The who field has s/who/\\fIwho\\fP/ > no prefix for special identifiers, a > .B user: > or > .B u: > prefix for regular users, and a > .B group: > or > .B g: > prefix for regular groups. > .PP > The entries are comma, whitespace or newline separated. s/whitespace/whitespace,/ > > Flags and permissions have single-letter as well as long forms as listed under s/forms/forms,/ > .IR "ACL Flags" , > .IR "ACL Entry Flags" , > and > .IR Permissions . If you follow my suggestion about capitalization in the ".SS" entries, you'll need to change the capitalization in the above phrases. > When the single-letter forms are used, the flags or permissions are > concatenated. When the long forms are used, the flags or permissions are > separated by slashes. To align permissions or flags vertically, dashes can be > use for padding. s/use/used/ > > .SH SETTING AND MODIFYING FILE PERMISSIONS > The access permissions for a file can either be set by assigning an access > control list (setrichacl) or by changing the file mode permission bits (chmod). Use .RB ( setrichacl (1)) for cross-reference. Use .RB ( chmod (1)). > In addition, a file can inherit an ACL from its parent > directory at create time; the inherited ACL is then further s/create/creation/ > restricted by the creating system call's mode parameter (see the creat(2) > manual page). creat(2) is pretty much history. I suggest writing (as given to .BR open (2), .BR mkdir (2), and similar). And here, I think we need a statement about whether the process umask has an effect or not... > > .SS Assigning An Access Control List > When assigning an ACL to a file, unless explicitly specified, the owner, group, > and other file masks will be computed from the ACL entries as described in > section > .IR "COMPUTING THE MAXIMUM FILE MASKS" . > The owner, group, and other file mode permission bits are then each set from > the owner, group, and other file mask as follows: > .IP \(bu 4 > If the file mask includes the > .B r > permission, the read > file mode permission bit will be set. > .IP \(bu > If the file mask includes the > .B w > or > .B p > permission, the write file mode permission bit will be set. > .IP \(bu > If the file mask includes the > .B x > permission, the execute file mode permission bit will be set. > .PP > If the ACL can be represented exactly by the file mode > permission bits, the file permission bits are set to match the access control > list and the ACL is not stored. (When the reverse happens and s/and/and the/ > ACL of a file is requested which doesn't have an explicit > ACL, the file mode permission bits are converted into an > equivalent richacl.) > > .SS Changing The File Mode Permission Bits I'd use lower case in the above for all words except the first > When changing the file mode permission bits with chmod(2), the owner, group, .BR chmod (2) > and other file permission bits are set to the permission bits in the new mode, > and the file masks each are set based on the new mode bits as follows: > .IP \(bu 4 > If the read bit in a set of permissions is set, the > .B r > permission in the corresponding file mask will be set. > .IP \(bu > If the write bit in a set of permissions is set, the > .B w > and > .B p > permissions in the corresponding file mask will be set. > .IP \(bu > If the execute bit in a set of permissions is set, the > .B x > permission in the corresponding file mask will be set. > .PP > In addition, the > .B masked > and > .B write_through > ACL flags are set. This has the > effect of limiting the permissions granted by the ACL to the file mode > permission bits; in addition, the owner is granted the owner mode bits and > others are granted the other mode bits. If the > .B auto_inherit > flag is set, the > .B protected > flag is also set to prevent the Automatic Inheritance algorithm from modifying > the ACL. > > .SS Permissions At File Create Time s/File Create/file-creation/ I'd use lower case in the above for all words except the first > When a directory has inheritable ACL entries, the following > happens when a file or directory is created inside that directory: > .RS 4 > .IP 1. 4 > A file created inside that directory will inherit all entries with the s/all entries with/all of the directories entries that/ > .B file_inherit > flag set, and all inheritance-related flags in the inherited entries will be > cleared. > > A subdirectory will inherit all entries with the > .B file_inherit > or > .B dir_inherit > flag set. Entries whose > .B no_propagate > flag is set will have all inheritance-related flags cleared. Entries whose > .B no_propagate > and > .B dir_inherit > flags are not set and whose > .B file_inherit > is set will have their > .B inherit_only > flag set. > .IP 2. > If the parent directory's ACL has the > .B auto_inherit > flag set, the inherited ACL will have its > .B auto_inherit > flag set, and all entries will have their > .B inherited > flag set. > .IP 3. > The three file masks are computed from the inherited ACL as described in > section > .IR "COMPUTING THE MAXIMUM FILE MASKS" . > .IP 4. > The three sets of permissions for the owner, the group, and for others in > the mode parameter of the creating system call are converted into sets of > richacl permissions as described in section s/in/in the/ > .IR "Changing The File Mode Permission Bits" . > Any richacl permissions not included in those sets are > removed from the owner, group, and other file masks. The file mode permission > bits are then computed from the file masks as described in section s/in/in the/ > .IR "Assigning An Access Control List" . > .IP 5. > The > .B masked > ACL flag is set. The > .B write_through > ACL flag remains cleared. In addition, if the > .B auto_inherit > flag of the inherited ACL is set, the > .B protected > flag is also set to prevent the Automatic Inheritance algorithm from modifying > the ACL. > .RE > .PP > When a directory does not have inheritable ACL entries, files > and directories created inside that directory will not be assigned access > control lists and the file mode permission bits will be set to (mode\ &\ > ~umask). will be set to (mode & umask) where .I mode is the permission mode argument of the relevant system call and .I umask is the process umask (see .BR umask (2)). > > .SS Automatic Inheritance I'd use lower case in the above for all words except the first > Automatic Inheritance allows permission changes to propagate from a directory > to files and subdirectories inside that directory, recursively. Carrying out > this propagation of permissions is the responsibility of the process changing > the directory permissions (usually, setrichacl(1)). I'm confused by the previous sentence. the feature is labeled "Automatic Inheritance", implying that the user/process need do nothing. The next sentence says "propagation ... is the responsibility of the process". These two points seem contradictory. I think something more needs to be said here. > > A significant limitation is that this mechanism works only as long as files > are created without explicitly specifying the file permissions to use. The > standard system calls for creating files an directories (creat(2), open(2), > mkdir(2), mkfifo(2), mknod(2)) all have mandatory mode parameters which define Format that system call list as .RB ( creat (2), .BR open (2), .BR mkdir (2), .BR mknod (2)) Note that I removed mkfifo(): it's a library functionlayered on mkonod(2). > the maximum allowed permissions of the new files. To take account of this > restriction, the > .B protected > ACL flag must be set if the > .B inherited > flag is set. This effectively disables Automatic Inheritance for that > particular file. > > Automatic Inheritance still remains useful for network protocols like NFSv4 and > SMB, which both support creating files and directories without defining which > permissions: they can implement those operations by using the standard system > calls and by then undoing the effect of applying the mode parameters. > > When the ACL of a directory is changed, the following should Why "should"? > happen for each entry inside that directory (for each \(lqchild\(rq): Make the preceding line: happen for each entry (\(lqchild\(rq) inside that directory: > .IP 1. 4 > If the entry is a symblic link, skip the child. > .IP 2. > If the > .B auto_inherit > flag of the entry's ACL is not set or the > .B protected > flag is set, skip the child. > .IP 3. > With the child's ACL: > .RS 4 > .IP 1. 4 s/1./a)/ (i.e., use a different labeling scheme for the sublist) > If the > .B defaulted > flag is set, replace the ACL with an empty ACL > with the > .B auto_inherit > flag set. > .IP 2. s/2./b)/ > Delete all entries which have the > .B inherited > flag set. > .IP 3. s/3./c)/ > Append all entries inherited from the parent directory according to step 1 of > the algorithm described under > .IR "Permissions At File Create Time". > Set the > .B inherited > flag of each of these entries. > .IP 4. s/4./d)/ > Recompute the file masks. > .RE > .IP 4. > If the child is a directory, recursively apply this algorithm. > > .SH ACCESS CHECK ALGORITHM > > When a process requests a particular kind of access to a file defined by a set s/defined/protected/ (?) > of richacl permissions, the following algorithm determines if the access is s/if/whether/ > granted or denied: > > .IP 1. 4 > If the > .B masked > ACL flag is set, then: > .RS 4 > .IP 1. 4 s/1./a)/ Use a different numbering scheme for sublists. > if the s/if/If/ > .B write_through > ACL flag is set, then: > .RS 4 > .IP \(bu 4 > if the requesting process is the file owner, then access is granted if the s/if/If/ > owner mask includes the requested permissions, and is otherwise denied. > .IP \(bu > if the requesting process is not the file owner, is not in the owning group, s/if/If/ > and no ACL entries other than > .B everyone@ > match the process, then access is granted if the other mask includes the > requested permissions, and is otherwise denied. > .RE > .IP 2. s/2./b)/ > if any of the following is true: s/if/If/ > .RS 4 > .IP \(bu 4 > the requesting process is the file owner and the owner mask does no include all s/no /not / > requested permissions, > .IP \(bu 4 > the requesting process is not the file owner and it is in the owning group or > matches any ACL entries other than > .BR everyone@ , > and the group mask does no include all requested permissions, > .IP \(bu 4 > the requesting process is not the file owner, not in the owning group, it > matches no ACL entries other than > .BR everyone@ , > and the other mask does no include all requested permissions, > .PP > then access is denied. > .RE > .RE > .IP 2. > Set the remaining permissions to the requested permissions. Go through all ACL > entries. For each entry: > .RS 4 > .IP 1. 4 s/1./a)/ Use a different numbering scheme for sublists. > if the > .B inherit_only > or > .B unmapped > flags are set, continue with the next ACL entry. > .IP 2. s/2./b)/ > if any of the following is true: > .RS 4 > .IP \(bu 4 > the entry's identifier is > .B owner@ > and the requesting process is the file owner, > .IP \(bu > the entry's identifier is > .B group@ > and the requesting process is in the owning group, > .IP \(bu > the entry's identifier is a user and the requesting process is owned by that > user, > .IP \(bu > the entry's identifier is a group and the requesting process is a member in > that group, > .IP \(bu > the entry's identifier is > .BR everyone@ , > .PP > the entry matches the process; proceed. Otherwise, continue with the next ACL s/proceed/proceed to the next step/ (?) > entry. > .RE > .IP 3. s/3./c)/ > If the entry denies any of the remaining permissions, access is denied. > .IP 4. s/4./d)/ > If the entry allows any of the remaining permissions, then: > .RS 4 > .IP \(bu 4 > if the > .B masked > ACL flag is set and the entry's identifier is not > .B owner@ > or > .BR everyone@ > or is a user entry matching the file owner, remove all permissions from the > remaining permissions which are both allowed by the entry and included in the > group mask, > .IP \(bu > otherwise, remove all permissions from the remaining permissions wich are > allowed by the entry. > .RE > .RE > .IP 3. > If there are no more remaining permissions, access is allowed. Otherwise, > access is denied. > > .SH COMPUTING THE MAXIMUM FILE MASKS > When setting an ACL and no file masks have been explicitly specified and when > inheriting an ACL from the parent directory, the following algorithm is used > for computing the file masks: > > .IP 1. 4 > Clear the owner, group, and other file masks. Remember which permissions have > already been processed (initially, the empty set). > .IP 2. > For each ACL entry: > .RS 4 > .IP \(bu 4 > If the > .B inherit_only > flag is set, skip the entry. > .IP \(bu 4 > Otherwise, compute which permissions the entry allows or denies that have not > been processed yet (the remaining permissions). > .IP \(bu > If the entry is an > .B owner@ > entry, add the remaining permissions to the owner mask for > .B allow > entries, and remove the remaining permissions from the owner mask for > .B deny > entries. > .IP \(bu > Otherwise, if the entry is an > .B everyone@ > entry, proceed as with > .B owner@ > entries but add or remove the remaining permissions from the owner, group, and > other file masks. > .IP \(bu > Otherwise, proceed as with > .B owner@ > entries but add or remove the remaining permissions from the owner and group > file masks. > .IP \(bu > Add the entry's permissions to the processed permissions. > .RE > .PP > The resulting file masks represent the ACL as closely as possible. With these > file masks, if the > .B masked > ACL flag is set, the effective permissions still stay the same. This page is in *desperate* need of *multiple* examples, starting simple, and building up in complexity, with walkthogh text explaining how the permisssions are interpreted and how the masks are generated. Having read the page multiple times (and having little knowledge of NFS ACLs), I'm still struggling to put all the pieces together. Probably some examples that relate to an NFS context would also be helpful. > .\" .SH BUGS > .SH AUTHOR > Written by Andreas Grünbacher . > > Please send your bug reports, suggested features and comments to the above address. > > .SH CONFORMING TO > Rich Access Control Lists are Linux-specific. > .SH SEE ALSO > .BR chmod (1), > .BR getrichacl (1), > .BR ls (1), > .BR setrichacl (1) > .BR stat (2), > .BR umask (2), > .BR acl (7) > .\" librichacl Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6EE2B7CA2 for ; Sun, 7 Feb 2016 10:35:58 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 5A2CE8F804B for ; Sun, 7 Feb 2016 08:35:58 -0800 (PST) Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by cuda.sgi.com with ESMTP id GOhxq5w14MlYwziz (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 07 Feb 2016 08:35:51 -0800 (PST) Received: by mail-wm0-f53.google.com with SMTP id p63so84967110wmp.1 for ; Sun, 07 Feb 2016 08:35:51 -0800 (PST) Subject: richacl(7) man page review comments References: <56B770B6.7040803@gmail.com> From: "Michael Kerrisk (man-pages)" Message-ID: <56B77262.7090107@gmail.com> Date: Sun, 7 Feb 2016 17:35:46 +0100 MIME-Version: 1.0 In-Reply-To: <56B770B6.7040803@gmail.com> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Andreas Gruenbacher Cc: Andreas Dilger , linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org, Christoph Hellwig , Linux API , Trond Myklebust , lkml , xfs@oss.sgi.com, "J. Bruce Fields" , mtk.manpages@gmail.com, linux-fsdevel@vger.kernel.org, Jeff Layton , linux-ext4@vger.kernel.org, Anna Schumaker SGkgQW5kcmVhcywKCkknbGwgcHJvYmFibHkgaGF2ZSBxdWl0ZSBhIGZldyBtb3JlIGNvbW1lbnRz IG9uIHRoaXMgcGFnZSBhcyBJIGdldCB0bwp1bmRlcnN0YW5kIFJpY2hBQ0xzIGJldHRlci4gSGVy ZSdzIHNvbWUgY29tbWVudHMgZnJvbSBhbiBpbml0aWFsCnJlYWRpbmcuCgpTbywgYW4gaW5pdGlh bCBjb21tZW50LiBJdCBzZWVtcyB0byBtZSB0byB0aGF0IHRoaXMgcGFnZSAoYnV0Cm5vdCBzZXRy aWNoYWNsKDEpIGFuZCBnZXRyaWNoYWNsKDEpKSBzaG91bGQgdWx0aW1hdGVseSBsYW5kIGluCm1h bi1wYWdlcyAoanVzdCBsaWtlIGFjbCg3KSksIHNpbmNlIHdlJ3JlIHRhbGtpbmcgYWJvdXQgYSBr ZXJuZWwKZmVhdHVyZS4gTWFrZSBzZW5zZT8KCj4gLlwiCj4gLlwiIFJpY2hhY2wgTWFudWFsIFBh Z2VzCj4gLlwiCj4gLlwiIENvcHlyaWdodCAoQykgMjAxNSAgUmVkIEhhdCwgSW5jLgo+IC5cIiBX cml0dGVuIGJ5IEFuZHJlYXMgR3J1ZW5iYWNoZXIgPGFncnVlbmJhQHJlZGhhdC5jb20+Cj4gLlwi IFRoaXMgaXMgZnJlZSBkb2N1bWVudGF0aW9uOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQv b3IKPiAuXCIgbW9kaWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVi bGljIExpY2Vuc2UgYXMKPiAuXCIgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5k YXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YKPiAuXCIgdGhlIExpY2Vuc2UsIG9yIChhdCB5b3Vy IG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCj4gLlwiCj4gLlwiIFRoZSBHTlUgR2VuZXJhbCBQ dWJsaWMgTGljZW5zZSdzIHJlZmVyZW5jZXMgdG8gIm9iamVjdCBjb2RlIgo+IC5cIiBhbmQgImV4 ZWN1dGFibGVzIiBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgdGhlIG91dHB1dCBvZiBhbnkKPiAu XCIgZG9jdW1lbnQgZm9ybWF0dGluZyBvciB0eXBlc2V0dGluZyBzeXN0ZW0sIGluY2x1ZGluZwo+ IC5cIiBpbnRlcm1lZGlhdGUgYW5kIHByaW50ZWQgb3V0cHV0Lgo+IC5cIgo+IC5cIiBUaGlzIG1h bnVhbCBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAo+ IC5cIiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3 YXJyYW50eSBvZgo+IC5cIiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNV TEFSIFBVUlBPU0UuICBTZWUgdGhlCj4gLlwiIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZv ciBtb3JlIGRldGFpbHMuCj4gLlwiCj4gLlwiIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNv cHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYwo+IC5cIiBMaWNlbnNlIGFsb25nIHdpdGggdGhp cyBtYW51YWwuICBJZiBub3QsIHNlZQo+IC5cIiA8aHR0cDovL3d3dy5nbnUub3JnL2xpY2Vuc2Vz Lz4uCj4gLlwiCj4gLmRlIFVSTAo+IFxcJDIgXChsYVVSTDogXFwkMSBcKHJhXFwkMwo+IC4uCj4g LmlmIFxuWy5nXSAubXNvIHd3dy50bWFjCj4gLlRIIFJJQ0hBQ0wgNyAyMDE1LTA5LTAxICJMaW51 eCIgIlJpY2ggQWNjZXNzIENvbnRyb2wgTGlzdHMiCj4gLlNIIE5BTUUKPiByaWNoYWNsIFwtIFJp Y2ggQWNjZXNzIENvbnRyb2wgTGlzdHMKPiAuU0ggREVTQ1JJUFRJT04KPiBSaWNoIEFjY2VzcyBD b250cm9sIExpc3RzIChyaWNoYWNscykgYXJlIGFuIGV4dGVuc2lvbiBvZiB0aGUgUE9TSVggZmls ZQoKRm9yIHdoYXQgaXQncyB3b3J0aCwgSSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aHdoaWxlIHRv IHN0YXJ0IHdpdGgKYSBjb25zaXN0ZW50IGFiYnJldmlhdGlvbiBjb21tZW50IGhlcmUgKGFuZCB1 c2UgaXQgdGhyb3VnaG91dCBhbGwgb2YgdGhlCm1hbiBwYWdlcyk6ICJSaWNoQUNMIiAob3IgInJp Y2hBQ0wiKSwgcmF0aGVyIHRoYW4gInJpY2hhY2wiOyB0aGF0IHNlZW1zCm1vcmUgY29uc2lzdGVu dCB3aXRoIHRoZSB0cmFkaXRpb25hbCBhYmJyZXZpYXRpb24gIkFDTCIuCgo+IHBlcm1pc3Npb24g bW9kZWwgdG8gc3VwcG9ydAoKTWFrZSB0aGlzOgoKcGVybWlzc2lvbiBtb2RlIChzZWUKLkJSIGFj bCAoNykpCnRvIHN1cHBvcnQKCj4gLlVSTCBodHRwczovL3Rvb2xzLmlldGYub3JnL3JmYy9yZmM1 NjYxLnR4dCAiTkZTdjQgQWNjZXNzIENvbnRyb2wgTGlzdHMiCj4gb24gbG9jYWwgYW5kIHJlbW90 ZS1tb3VudGVkIGZpbGVzeXN0ZW1zLgo+IAo+IFJpY2hhY2xzIHN1cHBvcnQgZmlsZSBtYXNrcyB3 aGljaCBhbGxvdyB0byBhcHBseSBhIGZpbGUgbW9kZSB0byBhbiBleGlzdGluZwoKcy93aGljaCBh bGxvdyB0byBhcHBseS93aGljaCBjYW4gYmUgdXNlZCB0byBhcHBseS8KCj4gTkZTdjQgQUNMIHdp dGhvdXQgZGVzdHJ1Y3RpdmUgc2lkZSBlZmZlY3RzOiB0aGUgZmlsZSBtb2RlIGRldGVybWluZXMg dGhlIHZhbHVlcwo+IG9mIHRoZSBmaWxlIG1hc2tzOyB0aGUgZmlsZSBtYXNrcyByZXN0cmljdCB0 aGUgcGVybWlzc2lvbnMgZ3JhbnRlZCBieSB0aGUgTkZTdjQKPiBBQ0wuICBXaGVuIGEgbGVzcyBy ZXN0cmljdGl2ZSBmaWxlIG1vZGUgaXMgYXBwbGllZCBsYXRlciwgdGhlIGZpbGUgbWFza3MgYmVj b21lCj4gbGVzcyByZXN0cmljdGl2ZSwgYW5kIG1vcmUgb2YgdGhlIG9yaWdpbmFsIHBlcm1pc3Np b25zIGNhbiBiZWNvbWUgZWZmZWN0aXZlLgo+IAo+IEEgcmljaGFjbCBjYW4gYWx3YXlzIGJlIHRy YW5zbGF0ZWQgaW50byBhbiBlcXVpdmFsZW50IE5GU3Y0IEFDTCB3aGljaCBncmFudHMKPiB0aGUg c2FtZSBwZXJtaXNzaW9ucy4KPiAKPiBSaWNoYWNscyBjYW4gYmUgZW5hYmxlZCBvbiBzdXBwb3J0 ZWQgZmlsZXN5c3RlbXMuIFRoaXMgZGlzYWJsZXMgUE9TSVggQWNjZXNzCj4gQ29udHJvbCBMaXN0 czsgdGhlIHR3byBBQ0wgbW9kZWxzIHdpbGwgbm90IGNvZXhpc3Qgb24gdGhlIHNhbWUgZmlsZXN5 c3RlbS4KCnMvd2lsbCBub3QvY2FuIG5vdC8gPwoKPiAKPiBXaGVuIHVzZWQgb24gYSBmaWxlc3lz dGVtIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCByaWNoYWNscywgdGhlIGdldHJpY2hhY2wgYW5kCgpV c2UKLkJSIGdldHJpY2hhY2wgKDEpCmZvciBjcm9zcy1yZWZlcmVuY2VzLgoKPiBzZXRyaWNoYWNs IHV0aWxpdGllcyB3aWxsIG9wZXJhdGUgb24gdGhlIGZpbGUgcGVybWlzc2lvbiBiaXRzIGluc3Rl YWQ6Cj4gZ2V0cmljaGFjbCB3aWxsIGRpc3BsYXkgdGhlIGZpbGUgcGVybWlzc2lvbiBiaXRzIGFz IGEgcmljaGFjbDsgd2hlbiBhIHJpY2hhY2wKClVzZQouQlIgZ2V0cmljaGFjbCAoMSkKZm9yIGNy b3NzLXJlZmVyZW5jZXMuCgo+IGlzIHNldCB3aXRoIHNldHJpY2hhY2wgd2hpY2ggY2FuIGJlIHJl cHJlc2VudGVkIGV4YWN0bHkgYnkgdGhlIGZpbGUgcGVybWlzc2lvbgoKVXNlCi5CUiBzZXRyaWNo YWNsICgxKQpmb3IgY3Jvc3MtcmVmZXJlbmNlcy4KCj4gYml0cywgc2V0cmljaGFjbCB3aWxsIHNl dCB0aGUgZmlsZSBwZXJtaXNzaW9uIGJpdHMgaW5zdGVhZC4KClVzZQouQlIgc2V0cmljaGFjbCAo MSkKZm9yIGNyb3NzLXJlZmVyZW5jZXMuCgpIZXJlLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGhlbHBm dWwgdG8gYWRkIGEgc2VudGVuY2U6CgoiQW4gYXR0ZW1wdCB0byBzZXQgYSByaWNoYWNsIHRoYXQg Y2Fubm90IGJlIHJlcHJlc2VudGVkIGV4YWN0bHkgYnkgdGhlCmZpbGUgcGVybWlzc2lvbiBiaXRz IHJlc3VsdHMgaW4gYW4gZXJyb3IuIgoKKElmIHRoYXQgc2VudGVuY2UgaXMgY29ycmVjdCwgb2Yg Y291cnNlLikKCj4gCj4gLlNIIFNUUlVDVFVSRSBPRiBSSUNIQUNMUwoKRm9yIGFsbCBvZiB0aGUg Im5vbnN0YW5kYXJkIiAoc2VlIG1hbi1wYWdlcyg3KSkgIi5TSCIgc2VjdGlvbnMgaGVyZSwgSSdk CmJlIGluY2xpbmVkIHRvIHN3aXRjaCB0byB1c2luZyAiLlNTIiBzdWJzZWN0aW9ucy4gVGhlcmUg YXJlIGRvd25zaWRlcyB0bwptdWx0aXBsZSBub25zdGFuZGFyZCBzZWN0aW9uIGhlYWRpbmdzIChl LmcuLCBhdXRvbWF0ZWQgVE9DcyBmb3IKU2VjdGlvbiBoZWFkaW5ncyBiZWNvbWUgY2x1bXN5IGFu ZCBsb25nKSwgYW5kIEkgZG9uJ3QgdGhpbmsgeW91ciB1c2Ugb2YKLlNIIHZzIC5TUyByZWFsbHkg aGVscHMgbXVjaCB0byBzdHJ1Y3R1cmUgdGhlIGluZm9ybWF0aW9uIGluIHRoaXMgcGFnZS4KCj4g Cj4gUmljaGFjbHMgY29uc2lzdCBvZiBhIG51bWJlciBvZiBBQ0wgZW50cmllcywgdGhyZWUgZmls ZSBtYXNrcywgYW5kIHNvbWUgZmxhZ3MuCgpzL3NvbWUgZmxhZ3MuL3NvbWUgZmxhZ3Mgc3BlY2lm eWluZyBhdHRyaWJ1dGVzIG9mIHRoZSBBQ0wgYXMgd2hvbGUgKGJ5CmNvbnRyYXN0IHdpdGggdGhl IHBlci1BQ0wtZW50cnkgZmxhZ3MgZGVzY3JpYmVkIGJlbG93KS4vCgo+IEVhY2ggb2YgdGhlIEFD TCBlbnRyaWVzIGFsbG93cyBvciBkZW5pZXMgc29tZSBwZXJtaXNzaW9ucyB0byBhIHBhcnRpY3Vs YXIgdXNlciwKPiBncm91cCwgb3Igc3BlY2lhbCBlbnRpdHkuIEVhY2ggYWNsIGVudHJ5IGNvbnNp c3RzIG9mOgoKcy9hY2wvLwoKPiAuSVAgXChidSA0Cj4gVGhlIHVzZXIgKHdpdGggcHJlZml4Cgpz L1RoZSB1c2VyL0EgdGFnIHdoaWNoIHNwZWNpZmllcyB0aGUgdXNlci8KCihJcyAidGFnIiB0aGUg cmlnaHQgd29yZD8gSW4gYW55IGNhc2UsIHdoYXQgd291bGQgaGVscGZ1bCB0byBoYXZlIGhlcmUK aXMgdGhlIGdlbmVyaWMgdGVybSBmb3IgdGhpcyBjb21wb25lbnQgb2YgdGhlIEFDTC4pCgo+IC5C IHVzZXI6Cj4gb3IKPiAuQlIgdTogKSwKPiBncm91cCAod2l0aCBwcmVmaXgKPiAuQiBncm91cDoK PiBvcgo+IC5CUiBnOiApLAo+IG9yIHNwZWNpYWwgaWRlbnRpZmllciB0aGUgZW50cnkgYXBwbGll cyB0by4gU3BlY2lhbAo+IGlkZW50aWZpZXJzIGNhbiBiZSB0aGUgZmlsZSBvd25lcgo+IC5SQiAo IG93bmVyQCApLAo+IHRoZSBvd25pbmcgZ3JvdXAKPiAuUkIgKCBncm91cEAgKSwKPiBvciBldmVy eW9uZQo+IC5SQiAoIGV2ZXJ5b25lQCApLgo+IC5JUCBcKGJ1Cj4gQSBzZXQgb2YgcGVybWlzc2lv bnMgdGhlIGVudHJ5IGFsbG93cyBvciBkZW5pZXMuCj4gLklQIFwoYnUKPiBBIHNldCBvZiBmbGFn cyB0aGF0IGluZGljYXRlIHdoZXRoZXIgdGhlIHVzZXIgb3IgZ3JvdXAgaWRlbnRpZmllciBpcyBt YXBwZWQgb3IKPiB1bm1hcHBlZCwgYW5kIHdoZXRoZXIgdGhlIGVudHJ5IGhhcyBiZWVuIGFuZCBj YW4gYmUgaW5oZXJpdGVkLgo+IC5JUCBcKGJ1IDQKPiBBIGZpZWxkIGluZGljYXRpbmcgd2hldGhl ciB0aGUgZW50cnkgYWxsb3dzIG9yIGRlbmllcyBhY2Nlc3MuCj4gLlBQCj4gVGhlIG93bmVyLCBn cm91cCwgYW5kIG90aGVyIGZpbGUgbWFza3MgZnVydGhlciBjb250cm9sIHdoaWNoIHBlcm1pc3Np b25zIHRoZQo+IEFDTCBncmFudHMsIHN1YmplY3QgdG8gdGhlCj4gLkIgbWFza2VkCj4gLlJCICgg bSApCj4gYW5kCj4gLkIgd3JpdGVfdGhyb3VnaAo+IC5SQiAoIHcgKQo+IEFDTCBmbGFncy4KPiAK PiBOb3RlIHRoYXQgZW50cmllcyB3aXRoIHRoZSBpZGVudGlmaWVyCj4gLkIgZXZlcnlvbmVACj4g YXBwbHkgdG8gYWxsIHByb2Nlc3Nlcywgd2hlcmVhcyB0aGUgXChscW90aGVyXChycSBmaWxlIHBl cm1pc3Npb25zIGFuZAo+IFwobHFvdGhlclwocnEgZW50cmllcyBpbiBQT1NJWCBBQ0xzIGFwcGx5 IHRvIGFsbCBwcm9jZXNzZXMgd2hpY2ggYXJlIG5vdCB0aGUKPiBvd25lciwgYXJlIG5vdCBpbiB0 aGUgb3duaW5nIGdyb3VwLCBhbmQgZG8gbm90IG1hdGNoIGEgdXNlciBvciBncm91cCBtZW50aW9u ZWQKPiBpbiB0aGUgYWNsLgoKcy9hY2wvQUNMLwoKPiBSaWNoYWNscyBkbyBub3QgaGF2ZSBzZXBh cmF0ZSBcKGxxYWNjZXNzXChycSBBQ0xzIHRoYXQgZGVmaW5lIHRoZSBhY2Nlc3MKPiBwZXJtaXNz aW9ucyBhbmQgXChscWRlZmF1bHRcKHJxIEFDTHMgdGhhdCBkZWZpbmUgdGhlIGluaGVyaXRhYmxl IHBlcm1pc3Npb25zIGFzCj4gUE9TSVggQUNMcy4KCkknZCByZXN0cnVjdHVyZSB0aGUgcHJlY2Vk aW5nIHNlbnRlbmNlIGFzOgoKIlVubGlrZSBQT1NJWCBBQ0xzLCByaWNoYWNscyBkbyBub3QuLi4u IHRoYXQgZGVmaW5lIHRoZSBpbmhlcml0YWJsZQpwZXJtaXNzaW9ucy4iCgo+IEluc3RlYWQsIHdo ZXRoZXIgYW4gQUNMIGVudHJ5IGlzIGVmZmVjdGl2ZSBkdXJpbmcgYWNjZXNzIGNoZWNrcwo+IGFu ZC9vciBpbmhlcml0YWJsZSBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBBQ0wgZW50cnkgZmxhZ3MuCj4g Cj4gLlNTIEFDTCBGbGFncwoKSSdkIHVzZSBsb3dlciBjYXNlIGluIHRoZSBhYm92ZSBmb3IgYWxs IHdvcmRzIGV4Y2VwdCB0aGUgZmlyc3QuCihUaGF0J3MgdGhlIGNvbnZlbnRpb24gaW4gbWFuLXBh Z2VzLikKCj4gCj4gVGhlIGZvbGxvd2luZyBmbGFncyBvbiBBQ0xzIGFyZSBkZWZpbmVkOgo+IAo+ IC5SUyA0Cj4gLkhQIDQKCnMvNC84LyBpbiB0aGUgcHJlY2VkaW5nIHR3byBsaW5lcy4gSSB0aGlu ayBtb3JlIGluZGVudGF0aW9uIHdvdWxkIG1ha2UKdGhpcyAoYW5kIHRoZSBzaW1pbGFyIGxpc3Rz IGJlbG93KSBtb3JlIHJlYWRhYmxlLgoKPiAuQiBtYXNrZWQKPiAuUkIgKCBtICk6CgpJJ2Qgd3Jp dGUgZWFjaCBvZiB0aGVzZSBsaXN0IGVudHJpZXMgc3RhcnRpbmcgaGVyZSwgYW5kIGJlbG93LCBp biB0aGUKZm9ybToKCi5CUiBtYXNrZWQgIlwgKCIgbSApOgoKVGhpcyBmb3JtIGlzIGEgbGl0dGxl IGVhc2llciB0byByZWFkIGluIHRoZSBzb3VyY2UsIGFuZAppdCBmb3JjZXMganVzdCBhIHNpbmds ZSBzcGFjZSBiZWZvcmUgdGhlICIoIiwgd2hpY2ggbG9va3MKYSBsaXR0bGUgYmV0dGVyLCBJIGZp bmQuCgo+IFdoZW4gc2V0LCB0aGUgZmlsZSBtYXNrcyBkZWZpbmUgdXBwZXIgbGltaXRzIG9uIHRo ZSBwZXJtaXNzaW9ucyB0aGUgQUNMIG1heQo+IGdyYW50Lgo+IC5IUAo+IC5CIHdyaXRlX3Rocm91 Z2gKPiAuUkIgKCB3ICk6Cj4gV2hlbiB0aGlzIGZsYWcgYW5kIHRoZSBtYXNrZWQgZmxhZyBhcmUg Ym90aCBzZXQsIHRoZSBvd25lciBhbmQgb3RoZXIgZmlsZSBtYXNrcwoKLkIgbWFza2VkCgo+IGRl ZmluZSB0aGUgYWN0dWFsIHBlcm1pc3Npb25zIGdyYW50ZWQgdG8gdGhlIGZpbGUgb3duZXIgYW5k IHRvIG90aGVycyBpbnN0ZWFkCj4gb2YgYW4gdXBwZXIgbGltaXQuCj4gLkhQCj4gLkIgYXV0b19p bmhlcml0Cj4gLlJCICggYSApOgo+IEF1dG9tYXRpYyBJbmhlcml0YW5jZSBpcyBlbmFibGVkIGZv ciB0aGUgZmlsZSB0aGUgQUNMIGlzCj4gYXR0YWNoZWQgdG8uIFNlZQo+IC5JUiAiQXV0b21hdGlj IEluaGVyaXRhbmNlIiAuCj4gLkhQCj4gLkIgcHJvdGVjdGVkCj4gLlJCICggcCApOgo+IFRoZSBB Q0wgaXMgcHJvdGVjdGVkIGZyb20gbW9kaWZpY2F0aW9uIGJ5IEF1dG9tYXRpYwo+IEluaGVyaXRh bmNlLgo+IC5IUAo+IC5CIGRlZmF1bHRlZAo+IC5SQiAoIGQgKToKPiBUaGUgQUNMIGhhcyBiZWVu IGFzc2lnbmVkIGJ5IGRlZmF1bHQuIEF1dG9tYXRpYyBJbmhlcml0YW5jZSBzaG91bGQgY29tcGxl dGVseQo+IHJlcGxhY2UgdGhlIEFDTC4KPiAuUkUKPiAKPiAuU1MgQUNMIEVudHJ5IEZsYWdzCj4g Cj4gVGhlIGZvbGxvd2luZyBmbGFncyBvbiBBQ0wgZW50cmllcyBhcmUgZGVmaW5lZDoKPiAKPiAu UlMgNAo+IC5IUCA0CgpzLzQvOC8gaW4gdGhlIHByZWNlZGluZyB0d28gbGluZXMuCgo+IC5CIGZp bGVfaW5oZXJpdAo+IC5SQiAoIGYgKToKPiBUaGUgZW50cnkgaXMgaW5oZXJpdGFibGUgZm9yIGZp bGVzLgo+IC5IUAo+IC5CIGRpcl9pbmhlcml0Cj4gLlJCICggZCApOgo+IFRoZSBlbnRyeSBpcyBp bmhlcml0YWJsZSBmb3IgZGlyZWN0b3JpZXMuCj4gLkhQCj4gLkIgbm9fcHJvcGFnYXRlCj4gLlJC ICggbiApOgo+IEluaGVyaXRhbmNlIHN0b3BzIGF0IHRoZSBuZXh0IHN1YmRpcmVjdG9yeSBsZXZl bC4KPiAuSFAKPiAuQiBpbmhlcml0X29ubHkKPiAuUkIgKCBpICk6Cj4gVGhlIGVudHJ5IGRlZmlu ZXMgaW5oZXJpdGFibGUgcGVybWlzc2lvbnMgb25seSBhbmQgaXMgaWdub3JlZCBmb3IgYWNjZXNz Cj4gY2hlY2tpbmcuCj4gLkhQCj4gLkIgaW5oZXJpdGVkCj4gLlJCICggYSApOgo+IFRoZSBlbnRy eSBoYXMgYmVlbiBhdXRvbWF0aWNhbGx5IGluaGVyaXRlZCBmcm9tIHRoZSBwYXJlbnQgZGlyZWN0 b3J5OyB0aGUKPiBBQ0wncyBhdXRvX2luaGVyaXQKClVzZQouQiBhdXRvX2luaGVyaXQKCj4gLlJC ICggYSApCj4gZmxhZyBzaG91bGQgYmUgb24uCj4gLkhQCj4gLkIgdW5tYXBwZWQKPiAuUkIgKCB1 ICk6Cj4gVGhlIHVzZXIgb3IgZ3JvdXAgaWRlbnRpZmllciBpcyBhIHRleHR1YWwgc3RyaW5nIGFu ZCBoYXMgbm8gbWFwcGluZyB0byBhCj4gbnVtZXJpYyB1c2VyIG9yIGdyb3VwIGlkZW50aWZpZXIu CgpTbyBoZXJlLCBJIHRoaW5rIHRoZXJlIHNob3VsZCBiZSBhIHNlbnRlbmNlIHRoYXQgZXhwbGFp bnMgaG93IGEgbWVhbmluZwppcyBhdHRhY2hlZCB0byB0aGUgc3RyaW5ncz8gSXMgdGhpcyBmb3Ig TkZTLCBmb3IgV2luZG93cywgZm9yIHNvbWV0aGluZwplbHNlPwoKPiAuUkUKPiAKPiAuU1MgUGVy bWlzc2lvbnMKPiAKPiBUaGUgZm9sbG93aW5nIHBlcm1pc3Npb25zIGFyZSBkZWZpbmVkIGZvciBy aWNoYWNsIGVudHJpZXMgYW5kIGZvciB0aGUgdGhyZWUKPiBmaWxlIG1hc2tzOgo+IAo+IC5SUyA0 Cj4gLkhQIDQKCnMvNC84LyBpbiB0aGUgcHJlY2VkaW5nIHR3byBsaW5lcy4KCj4gLkIgcmVhZF9k YXRhCj4gLwo+IC5CIGxpc3RfZGlyZWN0b3J5Cj4gLlJCICggciApOgoKUmVwbGFjZSB0aGUgcHJl Y2VkaW5nIGZvdXIgbGluZXMgYnkKCi5CUiByZWFkX2RhdGEgLyBsaXN0X2RpcmVjdG9yeSAiXCAo IiByICkKCmFuZCBkbyBzaW1pbGFyIGZvciB0aGUgbmV4dCB0d28gbGlzdCBlbnRyaWVkIGJlbG93 LgpOb3RlIHRoYXQgIlwgKCIgd2lsbCBmb3JjZSBqdXN0IGEgc2luZ2xrZSBzcGFjZSBiZWZvcmUg dGhlICIoIi4KCj4gUmVhZCB0aGUgZGF0YSBvZiBhIGZpbGUuCj4gTGlzdCB0aGUgY29udGVudHMg b2YgYSBkaXJlY3RvcnkuCgpJbiB0aGUgYWJvdmUgbGlzdCBlbnRyeSwgYW5kIHRoZSBuZXh0IHR3 bywgSSBmaW5kIHRoZSBsYXlvdXQgKCJ4eHgveXl5ICh6KSIpCmNvbmZ1c2luZy4gQSBjbG9zZXIg cmVhZGluZyBpbmRpY2F0ZXMgdGhhdCBpbiBlYWNoIGNhc2UsIHRoZSAieHh4IgphcHBsaWVzIGZv ciBmaWxlcyBhbmQgaGUgInl5eSIgaXMgZm9yIGRpcmVjdG9yaWVzLiBCdXQgSSB0aGluayB0aGUg dGV4dApjb3VsZCBtYWtlIHRoaXMgcG9pbnQgYSBsaXR0bGUgZWFzaWVyIHRvIGdyYXNwLiBJbiBl YWNoIG9mIHRoZXNlIHRocmVlCmxpc3QgZW50cmllcyB0aGlzIGNvdWxkIGJlIGRvbmUgc29tZXRo aW5nIGxrZSB0aGUgZm9sbG93aW5nOgoKIkZvciBhIGZpbGU6IHJlYWQgdGhlIGRhdGEgb2YgdGhl IGZpbGUuIEZvciBhIGRpcmVjdG9yeTogbGlzdCB0aGUKY29udGVudHMgb2YgdGhlIGRpcmVjdG9y eS4iCgpCeSB0aGUgd2F5LCBjYW4gdGhlIHRlcm1zICJyZWFkX2RhdGEiIGFuZCAibGlzdF9kaXJl Y3RvcnkiIGJlIHVzZWQKaW50ZXJjaGFuZ2VhYmx5PyBUaGF0IGlzLCBjYW4geW91IGVtcGxveSAo c2F5KSAicmVhZF9kYXRhIiB3aGVuIHNldHRpbmcKYW4gQUNMIGVudHJ5IGZvciBhIGRpcmVjdG9y eT8gKEknbSBhc3N1bWluZyB0aGUgYW5zd2VyIGlzICJ5ZXMiLikKSWYgdGhlIHRlcm1zIGFyZSBq dXN0IGludGVyY2hhbmdlYWJsZSBzeW5vbnltcywgcGVyaGFzIGl0J3Mgd29ydGgKbWFraW5nIHRo YXQgcG9pbnQgZXhwbGljaXRseSBpbiB0aGUgdGV4dC4KCj4gLkhQCj4gLkIgd3JpdGVfZGF0YQo+ IC8KPiAuQiBhZGRfZmlsZQo+IC5SQiAoIHcgKToKPiBNb2RpZnkgdGhlIGRhdGEgb2YgYSBmaWxl LiBBZGQgYSBuZXcgZmlsZSBpbiBhIGRpcmVjdG9yeS4KClNlZSBhYm92ZSBjb21tZW50IHJlIGZp bGUvZGlyZWN0b3J5LgoKPiAuSFAKPiAuQiBhcHBlbmRfZGF0YQo+IC8KPiAuQiBhZGRfc3ViZGly ZWN0b3J5Cj4gLlJCICggcCApOgo+IE9wZW4gYSBmaWxlIGluIGFwcGVuZCBtb2RlLiBDcmVhdGUg YSBzdWJkaXJlY3RvcnkgaW4gYSBkaXJlY3RvcnkuCgpTbywgaW4gb3RoZXIgd29yZHMsIGlmIGFw cGVuZCBtb2RlIGlzIGRlbmllZCwgdGhlbiB0aGUgZmlsZSBjYW4gYmUKb3BlbmVkIGZvciB3cml0 aW5nIChjb250aW5nZW50IG9uIHdyaXRlIHBlcm1pc3Npb24gIGJlaW5nIGdyYW50ZWQpLCBidXQK Y2FuJ3QgYmUgb3BlbmVkIHdpdGggT19BUFBFTkQ/IElzIHRoYXQgY29ycmVjdD8gVGhpcyBwb2lu dCBuZWVkcyB0byBiZQptYWRlIGNsZWFyZXIuCgo+IC5IUAo+IC5CIGV4ZWN1dGUKPiAuUkIgKCB4 ICk6Cj4gRXhlY3V0ZSBhIGZpbGUuIFRyYXZlcnNlIC8gc2VhcmNoIGEgZGlyZWN0b3J5LgoKU2Vl IGFib3ZlIGNvbW1lbnQgcmUgZmlsZS9kaXJlY3RvcnkuCgo+IC5IUAo+IC5CIGRlbGV0ZV9jaGls ZAo+IC5SQiAoIGQgKToKPiBEZWxldGUgYSBmaWxlIG9yIGRpcmVjdG9yeSB3aXRoaW4gYSBkaXJl Y3RvcnkuCj4gLkhQCj4gLkIgZGVsZXRlCj4gLlJCICggRCApOgo+IERlbGV0ZSB0aGUgZmlsZSBv ciBkaXJlY3RvcnkuCj4gLkhQCj4gLkIgcmVhZF9hdHRyaWJ1dGVzCj4gLlJCICggYSApOgo+IFJl YWQgYmFzaWMgYXR0cmlidXRlcyBvZiBhIGZpbGUgb3IgZGlyZWN0b3J5LgoKV2hhdCBhcmUgImF0 dHJpYnV0ZXMiIGluIHRoaXMgY29udGV4dD8gRG9lcyB0aGlzIG1lYW4gc3RhdCgyKT8gTWFrZSB0 aGlzCmV4cGxpY2l0LgoKPiBUaGlzIHBlcm1pc3Npb24gaXMgYWx3YXlzIGltcGxpY2l0bHkgZ3Jh bnRlZC4KPiAuSFAKPiAuQiB3cml0ZV9hdHRyaWJ1dGVzCj4gLlJCICggQSApOgo+IENoYW5nZSB0 aGUgdGltZXMgYXNzb2NpYXRlZCB3aXRoIGEgZmlsZSBvciBkaXJlY3RvcnkgdG8gYW4gYXJiaXRy YXJ5IHZhbHVlLgo+IFRoaXMgcGVybWlzc2lvbiBpcyBhbHdheXMgaW1wbGljaXRseSBncmFudGVk IHRvIHRoZSBmaWxlIG93bmVyLgo+IC5IUAo+IC5CIHJlYWRfYWNsCj4gLlJCICggYyApOgo+IFJl YWQgdGhlIEFDTCBvZiBhIGZpbGUgb3IgZGlyZWN0b3J5LiBUaGlzIHBlcm1pc3Npb24gaXMgYWx3 YXlzCj4gaW1wbGljaXRseSBncmFudGVkLgo+IC5IUAo+IC5CIHdyaXRlX2FjbAo+IC5SQiAoIEMg KToKPiBDaGFuZ2UgdGhlIEFDTCBvciBmaWxlIG1vZGUgb2YgYSBmaWxlIG9yIGRpcmVjdG9yeS4K PiAuSFAKPiAuQiB3cml0ZV9vd25lcgo+IC5SQiAoIG8gKToKPiBUYWtlIG93bmVyc2hpcCBvZiBh IGZpbGUgb3IgZGlyZWN0b3J5LiAgQ2hhbmdlIHRoZSBvd25pbmcgZ3JvdXAgb2YgYSBmaWxlIG9y Cj4gZGlyZWN0b3J5IHRvIGEgZ3JvdXAgb2Ygd2hpY2ggdGhlIGNhbGxpbmcgcHJvY2VzcyBpcyBh IG1lbWJlci4KPiAuSFAKPiAuQiByZWFkX25hbWVkX2F0dHJzCj4gLlJCICggUiApLAo+IC5CIHdy aXRlX25hbWVkX2F0dHJzCj4gLlJCICggVyApLAo+IC5CIHN5bmNocm9uaXplCj4gLlJCICggUyAp LAo+IC5CIHdyaXRlX3JldGVudGlvbgo+IC5SQiAoIGUgKSwKPiAuQiB3cml0ZV9yZXRlbnRpb25f aG9sZAo+IC5SQiAoIEUgKToKPiBUaGVzZSBwZXJtaXNzaW9ucyBjYW4gYmUgc3RvcmVkLCBidXQg ZG8gbm90IGhhdmUgYSBsb2NhbCBtZWFuaW5nLgoKU28sIEkgdGhlbmsgdGhhdCBhIHNlbnRlbmNl IGhlcmUgc2hvdWxkIGV4cGxhaW4gd2h5IHRoZXNlIHBlcm1pc3Npb25zCmV4aXN0LiBJcyBpZiBm b3IgZnV0dXJlIGV4dGVuc2lvbiwgYmVjYXVzZSB0aGV5IGFyZSBtZWFuaW5nZnVsIGluIE5GUywK b3Igc29tZXRoaW5nIGVsc2U/Cgo+IC5SRQo+IAo+IC5TSCBURVhUIEZPUk0KPiAKPiBUaGUgY29t bW9uIHRleHR1YWwgcmVwcmVzZW50YXRpb24gb2YgcmljaGFjbCBjb25zaXN0cyBvZiB0aGUgY29s b24gc2VwYXJhdGVkCgpzL3JpY2hhY2wvcmljaGFjbHMvIChvciwgIlJpY2hBQ0xzIi8icmljaEFD THMiKQoKcy9jb2xvbiBzZXBhcmF0ZWQvY29sb24tc2VwYXJhdGVkLwoKPiBmaWVsZHMgb2YgdGhl IHRoZSBhY2wgZmxhZ3MsIGZpbGUgbWFza3MsIGFuZCBhY2wgZW50cmllcyBpbiB0aGUgZm9sbG93 aW5nCgpzL2FjbC9BQ0wvICgqMikKCj4gZm9ybWF0Ogo+IC5UUAo+IFxmQmZsYWdzOlxmUlxmSWFj bF9mbGFnc1xmUgo+IFRoZSBBQ0wgZmxhZ3MuCj4gLlRQCj4gXGZCb3duZXI6XGZSXGZJcGVybVxm UlxmQjo6bWFza1xmUiwgXGZCZ3JvdXA6XGZSXGZJcGVybVxmUlxmQjo6bWFza1xmUiwgXGZCb3Ro ZXI6XGZSXGZJcGVybVxmUlxmQjo6bWFza1xmUgo+IFRoZSBmaWxlIG1hc2tzIGFuZCB0aGVpciBw ZXJtaXNzaW9ucy4KPiAuVFAKPiBcZkl3aG9cZlJcZkI6XGZSXGZJcGVybVxmUlxmQjpcZlJcZklm bGFnc1xmUlxmQjphbGxvd1xmUiwgXGZJd2hvXGZSXGZCOlxmUlxmSXBlcm1cZlJcZkI6XGZSXGZJ ZmxhZ3NcZlJcZkI6ZGVueVxmUgo+IEZvciBlYWNoIEFDTCBlbnRyeSwgd2hvIHRoZSBlbnRyeSBh cHBsaWVzIHRvLCB0aGUgcGVybWlzc2lvbnMgb2YgdGhlIGVudHJ5LCB0aGUKPiBlbnRyeSBmbGFn cywgYW5kIHdoZXRoZXIgdGhlIGVudHJ5IGFsbG93cyBvciBkZW5pZXMgcGVybWlzc2lvbnMuICBU aGUgd2hvIGZpZWxkIGhhcwoKcy93aG8vXFxmSXdob1xcZlAvCgo+IG5vIHByZWZpeCBmb3Igc3Bl Y2lhbCBpZGVudGlmaWVycywgYQo+IC5CIHVzZXI6Cj4gb3IKPiAuQiB1Ogo+IHByZWZpeCBmb3Ig cmVndWxhciB1c2VycywgYW5kIGEKPiAuQiBncm91cDoKPiBvcgo+IC5CIGc6Cj4gcHJlZml4IGZv ciByZWd1bGFyIGdyb3Vwcy4KPiAuUFAKPiBUaGUgZW50cmllcyBhcmUgY29tbWEsIHdoaXRlc3Bh Y2Ugb3IgbmV3bGluZSBzZXBhcmF0ZWQuCgpzL3doaXRlc3BhY2Uvd2hpdGVzcGFjZSwvCgo+IAo+ IEZsYWdzIGFuZCBwZXJtaXNzaW9ucyBoYXZlIHNpbmdsZS1sZXR0ZXIgYXMgd2VsbCBhcyBsb25n IGZvcm1zIGFzIGxpc3RlZCB1bmRlcgoKcy9mb3Jtcy9mb3JtcywvCgo+IC5JUiAiQUNMIEZsYWdz IiAsCj4gLklSICJBQ0wgRW50cnkgRmxhZ3MiICwKPiBhbmQKPiAuSVIgUGVybWlzc2lvbnMgLgoK SWYgeW91IGZvbGxvdyBteSBzdWdnZXN0aW9uIGFib3V0IGNhcGl0YWxpemF0aW9uIGluIHRoZSAi LlNTIiBlbnRyaWVzLAp5b3UnbGwgbmVlZCB0byBjaGFuZ2UgdGhlIGNhcGl0YWxpemF0aW9uIGlu IHRoZSBhYm92ZSBwaHJhc2VzLgoKPiBXaGVuIHRoZSBzaW5nbGUtbGV0dGVyIGZvcm1zIGFyZSB1 c2VkLCB0aGUgZmxhZ3Mgb3IgcGVybWlzc2lvbnMgYXJlCj4gY29uY2F0ZW5hdGVkLiBXaGVuIHRo ZSBsb25nIGZvcm1zIGFyZSB1c2VkLCB0aGUgZmxhZ3Mgb3IgcGVybWlzc2lvbnMgYXJlCj4gc2Vw YXJhdGVkIGJ5IHNsYXNoZXMuICBUbyBhbGlnbiBwZXJtaXNzaW9ucyBvciBmbGFncyB2ZXJ0aWNh bGx5LCBkYXNoZXMgY2FuIGJlCj4gdXNlIGZvciBwYWRkaW5nLgoKcy91c2UvdXNlZC8KCj4gCj4g LlNIIFNFVFRJTkcgQU5EIE1PRElGWUlORyBGSUxFIFBFUk1JU1NJT05TCj4gVGhlIGFjY2VzcyBw ZXJtaXNzaW9ucyBmb3IgYSBmaWxlIGNhbiBlaXRoZXIgYmUgc2V0IGJ5IGFzc2lnbmluZyBhbiBh Y2Nlc3MKPiBjb250cm9sIGxpc3QgKHNldHJpY2hhY2wpIG9yIGJ5IGNoYW5naW5nIHRoZSBmaWxl IG1vZGUgcGVybWlzc2lvbiBiaXRzIChjaG1vZCkuCgpVc2UKLlJCICggc2V0cmljaGFjbCAoMSkp CmZvciBjcm9zcy1yZWZlcmVuY2UuCgpVc2UKLlJCICggY2htb2QgKDEpKS4KCj4gSW4gYWRkaXRp b24sIGEgZmlsZSBjYW4gaW5oZXJpdCBhbiBBQ0wgZnJvbSBpdHMgcGFyZW50Cj4gZGlyZWN0b3J5 IGF0IGNyZWF0ZSB0aW1lOyB0aGUgaW5oZXJpdGVkIEFDTCBpcyB0aGVuIGZ1cnRoZXIKCnMvY3Jl YXRlL2NyZWF0aW9uLwoKPiByZXN0cmljdGVkIGJ5IHRoZSBjcmVhdGluZyBzeXN0ZW0gY2FsbCdz IG1vZGUgcGFyYW1ldGVyIChzZWUgdGhlIGNyZWF0KDIpCj4gbWFudWFsIHBhZ2UpLgoKY3JlYXQo MikgaXMgcHJldHR5IG11Y2ggaGlzdG9yeS4gSSBzdWdnZXN0IHdyaXRpbmcKCihhcyBnaXZlbiB0 bwouQlIgb3BlbiAoMiksCi5CUiBta2RpciAoMiksCmFuZCBzaW1pbGFyKS4KCkFuZCBoZXJlLCBJ IHRoaW5rIHdlIG5lZWQgYSBzdGF0ZW1lbnQgYWJvdXQgd2hldGhlciB0aGUgcHJvY2VzcyB1bWFz awpoYXMgYW4gZWZmZWN0IG9yIG5vdC4uLgoKPiAKPiAuU1MgQXNzaWduaW5nIEFuIEFjY2VzcyBD b250cm9sIExpc3QKPiBXaGVuIGFzc2lnbmluZyBhbiBBQ0wgdG8gYSBmaWxlLCB1bmxlc3MgZXhw bGljaXRseSBzcGVjaWZpZWQsIHRoZSBvd25lciwgZ3JvdXAsCj4gYW5kIG90aGVyIGZpbGUgbWFz a3Mgd2lsbCBiZSBjb21wdXRlZCBmcm9tIHRoZSBBQ0wgZW50cmllcyBhcyBkZXNjcmliZWQgaW4K PiBzZWN0aW9uCj4gLklSICJDT01QVVRJTkcgVEhFIE1BWElNVU0gRklMRSBNQVNLUyIgLgo+IFRo ZSBvd25lciwgZ3JvdXAsIGFuZCBvdGhlciBmaWxlIG1vZGUgcGVybWlzc2lvbiBiaXRzIGFyZSB0 aGVuIGVhY2ggc2V0IGZyb20KPiB0aGUgb3duZXIsIGdyb3VwLCBhbmQgb3RoZXIgZmlsZSBtYXNr IGFzIGZvbGxvd3M6Cj4gLklQIFwoYnUgNAo+IElmIHRoZSBmaWxlIG1hc2sgaW5jbHVkZXMgdGhl Cj4gLkIgcgo+IHBlcm1pc3Npb24sIHRoZSByZWFkCj4gZmlsZSBtb2RlIHBlcm1pc3Npb24gYml0 IHdpbGwgYmUgc2V0Lgo+IC5JUCBcKGJ1Cj4gSWYgdGhlIGZpbGUgbWFzayBpbmNsdWRlcyB0aGUK PiAuQiB3Cj4gb3IKPiAuQiBwCj4gcGVybWlzc2lvbiwgdGhlIHdyaXRlIGZpbGUgbW9kZSBwZXJt aXNzaW9uIGJpdCB3aWxsIGJlIHNldC4KPiAuSVAgXChidQo+IElmIHRoZSBmaWxlIG1hc2sgaW5j bHVkZXMgdGhlCj4gLkIgeAo+IHBlcm1pc3Npb24sIHRoZSBleGVjdXRlIGZpbGUgbW9kZSBwZXJt aXNzaW9uIGJpdCB3aWxsIGJlIHNldC4KPiAuUFAKPiBJZiB0aGUgQUNMIGNhbiBiZSByZXByZXNl bnRlZCBleGFjdGx5IGJ5IHRoZSBmaWxlIG1vZGUKPiBwZXJtaXNzaW9uIGJpdHMsIHRoZSBmaWxl IHBlcm1pc3Npb24gYml0cyBhcmUgc2V0IHRvIG1hdGNoIHRoZSBhY2Nlc3MgY29udHJvbAo+IGxp c3QgYW5kIHRoZSBBQ0wgaXMgbm90IHN0b3JlZC4gIChXaGVuIHRoZSByZXZlcnNlIGhhcHBlbnMg YW5kCgpzL2FuZC9hbmQgdGhlLwoKPiBBQ0wgb2YgYSBmaWxlIGlzIHJlcXVlc3RlZCB3aGljaCBk b2Vzbid0IGhhdmUgYW4gZXhwbGljaXQKPiBBQ0wsIHRoZSBmaWxlIG1vZGUgcGVybWlzc2lvbiBi aXRzIGFyZSBjb252ZXJ0ZWQgaW50byBhbgo+IGVxdWl2YWxlbnQgcmljaGFjbC4pCj4gCj4gLlNT IENoYW5naW5nIFRoZSBGaWxlIE1vZGUgUGVybWlzc2lvbiBCaXRzCgpJJ2QgdXNlIGxvd2VyIGNh c2UgaW4gdGhlIGFib3ZlIGZvciBhbGwgd29yZHMgZXhjZXB0IHRoZSBmaXJzdAoKPiBXaGVuIGNo YW5naW5nIHRoZSBmaWxlIG1vZGUgcGVybWlzc2lvbiBiaXRzIHdpdGggY2htb2QoMiksIHRoZSBv d25lciwgZ3JvdXAsCgouQlIgY2htb2QgKDIpCgo+IGFuZCBvdGhlciBmaWxlIHBlcm1pc3Npb24g Yml0cyBhcmUgc2V0IHRvIHRoZSBwZXJtaXNzaW9uIGJpdHMgaW4gdGhlIG5ldyBtb2RlLAo+IGFu ZCB0aGUgZmlsZSBtYXNrcyBlYWNoIGFyZSBzZXQgYmFzZWQgb24gdGhlIG5ldyBtb2RlIGJpdHMg YXMgZm9sbG93czoKPiAuSVAgXChidSA0Cj4gSWYgdGhlIHJlYWQgYml0IGluIGEgc2V0IG9mIHBl cm1pc3Npb25zIGlzIHNldCwgdGhlCj4gLkIgcgo+IHBlcm1pc3Npb24gaW4gdGhlIGNvcnJlc3Bv bmRpbmcgZmlsZSBtYXNrIHdpbGwgYmUgc2V0Lgo+IC5JUCBcKGJ1Cj4gSWYgdGhlIHdyaXRlIGJp dCBpbiBhIHNldCBvZiBwZXJtaXNzaW9ucyBpcyBzZXQsIHRoZQo+IC5CIHcKPiBhbmQKPiAuQiBw Cj4gcGVybWlzc2lvbnMgaW4gdGhlIGNvcnJlc3BvbmRpbmcgZmlsZSBtYXNrIHdpbGwgYmUgc2V0 Lgo+IC5JUCBcKGJ1Cj4gSWYgdGhlIGV4ZWN1dGUgYml0IGluIGEgc2V0IG9mIHBlcm1pc3Npb25z IGlzIHNldCwgdGhlCj4gLkIgeAo+IHBlcm1pc3Npb24gaW4gdGhlIGNvcnJlc3BvbmRpbmcgZmls ZSBtYXNrIHdpbGwgYmUgc2V0Lgo+IC5QUAo+IEluIGFkZGl0aW9uLCB0aGUKPiAuQiBtYXNrZWQK PiBhbmQKPiAuQiB3cml0ZV90aHJvdWdoCj4gQUNMIGZsYWdzIGFyZSBzZXQuIFRoaXMgaGFzIHRo ZQo+IGVmZmVjdCBvZiBsaW1pdGluZyB0aGUgcGVybWlzc2lvbnMgZ3JhbnRlZCBieSB0aGUgQUNM IHRvIHRoZSBmaWxlIG1vZGUKPiBwZXJtaXNzaW9uIGJpdHM7IGluIGFkZGl0aW9uLCB0aGUgb3du ZXIgaXMgZ3JhbnRlZCB0aGUgb3duZXIgbW9kZSBiaXRzIGFuZAo+IG90aGVycyBhcmUgZ3JhbnRl ZCB0aGUgb3RoZXIgbW9kZSBiaXRzLiBJZiB0aGUKPiAuQiBhdXRvX2luaGVyaXQKPiBmbGFnIGlz IHNldCwgdGhlCj4gLkIgcHJvdGVjdGVkCj4gZmxhZyBpcyBhbHNvIHNldCB0byBwcmV2ZW50IHRo ZSBBdXRvbWF0aWMgSW5oZXJpdGFuY2UgYWxnb3JpdGhtIGZyb20gbW9kaWZ5aW5nCj4gdGhlIEFD TC4KPiAKPiAuU1MgUGVybWlzc2lvbnMgQXQgRmlsZSBDcmVhdGUgVGltZQoKcy9GaWxlIENyZWF0 ZS9maWxlLWNyZWF0aW9uLwoKSSdkIHVzZSBsb3dlciBjYXNlIGluIHRoZSBhYm92ZSBmb3IgYWxs IHdvcmRzIGV4Y2VwdCB0aGUgZmlyc3QKCj4gV2hlbiBhIGRpcmVjdG9yeSBoYXMgaW5oZXJpdGFi bGUgQUNMIGVudHJpZXMsIHRoZSBmb2xsb3dpbmcKPiBoYXBwZW5zIHdoZW4gYSBmaWxlIG9yIGRp cmVjdG9yeSBpcyBjcmVhdGVkIGluc2lkZSB0aGF0IGRpcmVjdG9yeToKPiAuUlMgNAo+IC5JUCAx LiA0Cj4gQSBmaWxlIGNyZWF0ZWQgaW5zaWRlIHRoYXQgZGlyZWN0b3J5IHdpbGwgaW5oZXJpdCBh bGwgZW50cmllcyB3aXRoIHRoZQoKcy9hbGwgZW50cmllcyB3aXRoL2FsbCBvZiB0aGUgZGlyZWN0 b3JpZXMgZW50cmllcyB0aGF0LwoKPiAuQiBmaWxlX2luaGVyaXQKPiBmbGFnIHNldCwgYW5kIGFs bCBpbmhlcml0YW5jZS1yZWxhdGVkIGZsYWdzIGluIHRoZSBpbmhlcml0ZWQgZW50cmllcyB3aWxs IGJlCj4gY2xlYXJlZC4KPiAKPiBBIHN1YmRpcmVjdG9yeSB3aWxsIGluaGVyaXQgYWxsIGVudHJp ZXMgd2l0aCB0aGUKPiAuQiBmaWxlX2luaGVyaXQKPiBvcgo+IC5CIGRpcl9pbmhlcml0Cj4gZmxh ZyBzZXQuICBFbnRyaWVzIHdob3NlCj4gLkIgbm9fcHJvcGFnYXRlCj4gZmxhZyBpcyBzZXQgd2ls bCBoYXZlIGFsbCBpbmhlcml0YW5jZS1yZWxhdGVkIGZsYWdzIGNsZWFyZWQuICBFbnRyaWVzIHdo b3NlCj4gLkIgbm9fcHJvcGFnYXRlCj4gYW5kCj4gLkIgZGlyX2luaGVyaXQKPiBmbGFncyBhcmUg bm90IHNldCBhbmQgd2hvc2UKPiAuQiBmaWxlX2luaGVyaXQKPiBpcyBzZXQgd2lsbCBoYXZlIHRo ZWlyCj4gLkIgaW5oZXJpdF9vbmx5Cj4gZmxhZyBzZXQuCj4gLklQIDIuCj4gSWYgdGhlIHBhcmVu dCBkaXJlY3RvcnkncyBBQ0wgaGFzIHRoZQo+IC5CIGF1dG9faW5oZXJpdAo+IGZsYWcgc2V0LCB0 aGUgaW5oZXJpdGVkIEFDTCB3aWxsIGhhdmUgaXRzCj4gLkIgYXV0b19pbmhlcml0Cj4gZmxhZyBz ZXQsIGFuZCBhbGwgZW50cmllcyB3aWxsIGhhdmUgdGhlaXIKPiAuQiBpbmhlcml0ZWQKPiBmbGFn IHNldC4KPiAuSVAgMy4KPiBUaGUgdGhyZWUgZmlsZSBtYXNrcyBhcmUgY29tcHV0ZWQgZnJvbSB0 aGUgaW5oZXJpdGVkIEFDTCBhcyBkZXNjcmliZWQgaW4KPiBzZWN0aW9uCj4gLklSICJDT01QVVRJ TkcgVEhFIE1BWElNVU0gRklMRSBNQVNLUyIgLgo+IC5JUCA0Lgo+IFRoZSB0aHJlZSBzZXRzIG9m IHBlcm1pc3Npb25zIGZvciB0aGUgb3duZXIsIHRoZSBncm91cCwgYW5kIGZvciBvdGhlcnMgaW4K PiB0aGUgbW9kZSBwYXJhbWV0ZXIgb2YgdGhlIGNyZWF0aW5nIHN5c3RlbSBjYWxsIGFyZSBjb252 ZXJ0ZWQgaW50byBzZXRzIG9mCj4gcmljaGFjbCBwZXJtaXNzaW9ucyBhcyBkZXNjcmliZWQgaW4g c2VjdGlvbgoKcy9pbi9pbiB0aGUvCgo+IC5JUiAiQ2hhbmdpbmcgVGhlIEZpbGUgTW9kZSBQZXJt aXNzaW9uIEJpdHMiIC4KPiBBbnkgcmljaGFjbCBwZXJtaXNzaW9ucyBub3QgaW5jbHVkZWQgaW4g dGhvc2Ugc2V0cyBhcmUKPiByZW1vdmVkIGZyb20gdGhlIG93bmVyLCBncm91cCwgYW5kIG90aGVy IGZpbGUgbWFza3MuIFRoZSBmaWxlIG1vZGUgcGVybWlzc2lvbgo+IGJpdHMgYXJlIHRoZW4gY29t cHV0ZWQgZnJvbSB0aGUgZmlsZSBtYXNrcyBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbgoKcy9pbi9p biB0aGUvCgo+IC5JUiAiQXNzaWduaW5nIEFuIEFjY2VzcyBDb250cm9sIExpc3QiIC4KPiAuSVAg NS4KPiBUaGUKPiAuQiBtYXNrZWQKPiBBQ0wgZmxhZyBpcyBzZXQuIFRoZQo+IC5CIHdyaXRlX3Ro cm91Z2gKPiBBQ0wgZmxhZyByZW1haW5zIGNsZWFyZWQuIEluIGFkZGl0aW9uLCBpZiB0aGUKPiAu QiBhdXRvX2luaGVyaXQKPiBmbGFnIG9mIHRoZSBpbmhlcml0ZWQgQUNMIGlzIHNldCwgdGhlCj4g LkIgcHJvdGVjdGVkCj4gZmxhZyBpcyBhbHNvIHNldCB0byBwcmV2ZW50IHRoZSBBdXRvbWF0aWMg SW5oZXJpdGFuY2UgYWxnb3JpdGhtIGZyb20gbW9kaWZ5aW5nCj4gdGhlIEFDTC4KPiAuUkUKPiAu UFAKPiBXaGVuIGEgZGlyZWN0b3J5IGRvZXMgbm90IGhhdmUgaW5oZXJpdGFibGUgQUNMIGVudHJp ZXMsIGZpbGVzCj4gYW5kIGRpcmVjdG9yaWVzIGNyZWF0ZWQgaW5zaWRlIHRoYXQgZGlyZWN0b3J5 IHdpbGwgbm90IGJlIGFzc2lnbmVkIGFjY2Vzcwo+IGNvbnRyb2wgbGlzdHMgYW5kIHRoZSBmaWxl IG1vZGUgcGVybWlzc2lvbiBiaXRzIHdpbGwgYmUgc2V0IHRvIChtb2RlXCAmXAo+IH51bWFzayku Cgp3aWxsIGJlIHNldCB0bwoKICAgIChtb2RlICYgdW1hc2spCgp3aGVyZQouSSBtb2RlCmlzIHRo ZSBwZXJtaXNzaW9uIG1vZGUgYXJndW1lbnQgb2YgdGhlIHJlbGV2YW50IHN5c3RlbSBjYWxsIGFu ZAouSSB1bWFzawppcyB0aGUgcHJvY2VzcyB1bWFzayAoc2VlCi5CUiB1bWFzayAoMikpLgoKPiAK PiAuU1MgQXV0b21hdGljIEluaGVyaXRhbmNlCgpJJ2QgdXNlIGxvd2VyIGNhc2UgaW4gdGhlIGFi b3ZlIGZvciBhbGwgd29yZHMgZXhjZXB0IHRoZSBmaXJzdAoKPiBBdXRvbWF0aWMgSW5oZXJpdGFu Y2UgYWxsb3dzIHBlcm1pc3Npb24gY2hhbmdlcyB0byBwcm9wYWdhdGUgZnJvbSBhIGRpcmVjdG9y eQo+IHRvIGZpbGVzIGFuZCBzdWJkaXJlY3RvcmllcyBpbnNpZGUgdGhhdCBkaXJlY3RvcnksIHJl Y3Vyc2l2ZWx5LiAgQ2Fycnlpbmcgb3V0Cj4gdGhpcyBwcm9wYWdhdGlvbiBvZiBwZXJtaXNzaW9u cyBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIHByb2Nlc3MgY2hhbmdpbmcKPiB0aGUgZGly ZWN0b3J5IHBlcm1pc3Npb25zICh1c3VhbGx5LCBzZXRyaWNoYWNsKDEpKS4KCkknbSBjb25mdXNl ZCBieSB0aGUgcHJldmlvdXMgc2VudGVuY2UuIHRoZSBmZWF0dXJlIGlzIGxhYmVsZWQgIkF1dG9t YXRpYwpJbmhlcml0YW5jZSIsIGltcGx5aW5nIHRoYXQgdGhlIHVzZXIvcHJvY2VzcyBuZWVkIGRv IG5vdGhpbmcuIFRoZSBuZXh0CnNlbnRlbmNlIHNheXMgInByb3BhZ2F0aW9uIC4uLiBpcyB0aGUg cmVzcG9uc2liaWxpdHkgb2YgdGhlIHByb2Nlc3MiLgpUaGVzZSB0d28gcG9pbnRzIHNlZW0gY29u dHJhZGljdG9yeS4gSSB0aGluayBzb21ldGhpbmcgbW9yZSBuZWVkcyB0byBiZQpzYWlkIGhlcmUu Cgo+IAo+IEEgc2lnbmlmaWNhbnQgbGltaXRhdGlvbiBpcyB0aGF0IHRoaXMgbWVjaGFuaXNtIHdv cmtzIG9ubHkgYXMgbG9uZyBhcyBmaWxlcwo+IGFyZSBjcmVhdGVkIHdpdGhvdXQgZXhwbGljaXRs eSBzcGVjaWZ5aW5nIHRoZSBmaWxlIHBlcm1pc3Npb25zIHRvIHVzZS4gVGhlCj4gc3RhbmRhcmQg c3lzdGVtIGNhbGxzIGZvciBjcmVhdGluZyBmaWxlcyBhbiBkaXJlY3RvcmllcyAoY3JlYXQoMiks IG9wZW4oMiksCj4gbWtkaXIoMiksIG1rZmlmbygyKSwgbWtub2QoMikpIGFsbCBoYXZlIG1hbmRh dG9yeSBtb2RlIHBhcmFtZXRlcnMgd2hpY2ggZGVmaW5lCgpGb3JtYXQgdGhhdCBzeXN0ZW0gY2Fs bCBsaXN0IGFzCi5SQiAoIGNyZWF0ICgyKSwKLkJSIG9wZW4gKDIpLAouQlIgbWtkaXIgKDIpLAou QlIgbWtub2QgKDIpKQoKTm90ZSB0aGF0IEkgcmVtb3ZlZCBta2ZpZm8oKTogaXQncyBhIGxpYnJh cnkgZnVuY3Rpb25sYXllcmVkIG9uCm1rb25vZCgyKS4KCj4gdGhlIG1heGltdW0gYWxsb3dlZCBw ZXJtaXNzaW9ucyBvZiB0aGUgbmV3IGZpbGVzLiBUbyB0YWtlIGFjY291bnQgb2YgdGhpcwo+IHJl c3RyaWN0aW9uLCB0aGUKPiAuQiBwcm90ZWN0ZWQKPiBBQ0wgZmxhZyBtdXN0IGJlIHNldCBpZiB0 aGUKPiAuQiBpbmhlcml0ZWQKPiBmbGFnIGlzIHNldC4gVGhpcyBlZmZlY3RpdmVseSBkaXNhYmxl cyBBdXRvbWF0aWMgSW5oZXJpdGFuY2UgZm9yIHRoYXQKPiBwYXJ0aWN1bGFyIGZpbGUuCj4gCj4g QXV0b21hdGljIEluaGVyaXRhbmNlIHN0aWxsIHJlbWFpbnMgdXNlZnVsIGZvciBuZXR3b3JrIHBy b3RvY29scyBsaWtlIE5GU3Y0IGFuZAo+IFNNQiwgd2hpY2ggYm90aCBzdXBwb3J0IGNyZWF0aW5n IGZpbGVzIGFuZCBkaXJlY3RvcmllcyB3aXRob3V0IGRlZmluaW5nIHdoaWNoCj4gcGVybWlzc2lv bnM6IHRoZXkgY2FuIGltcGxlbWVudCB0aG9zZSBvcGVyYXRpb25zIGJ5IHVzaW5nIHRoZSBzdGFu ZGFyZCBzeXN0ZW0KPiBjYWxscyBhbmQgYnkgdGhlbiB1bmRvaW5nIHRoZSBlZmZlY3Qgb2YgYXBw bHlpbmcgdGhlIG1vZGUgcGFyYW1ldGVycy4KPiAKPiBXaGVuIHRoZSBBQ0wgb2YgYSBkaXJlY3Rv cnkgaXMgY2hhbmdlZCwgdGhlIGZvbGxvd2luZyBzaG91bGQKCldoeSAic2hvdWxkIj8KCj4gaGFw cGVuIGZvciBlYWNoIGVudHJ5IGluc2lkZSB0aGF0IGRpcmVjdG9yeSAoZm9yIGVhY2ggXChscWNo aWxkXChycSk6CgpNYWtlIHRoZSBwcmVjZWRpbmcgbGluZToKCmhhcHBlbiBmb3IgZWFjaCBlbnRy eSAoXChscWNoaWxkXChycSkgaW5zaWRlIHRoYXQgZGlyZWN0b3J5OgoKPiAuSVAgMS4gNAo+IElm IHRoZSBlbnRyeSBpcyBhIHN5bWJsaWMgbGluaywgc2tpcCB0aGUgY2hpbGQuCj4gLklQIDIuCj4g SWYgdGhlCj4gLkIgYXV0b19pbmhlcml0Cj4gZmxhZyBvZiB0aGUgZW50cnkncyBBQ0wgaXMgbm90 IHNldCBvciB0aGUKPiAuQiBwcm90ZWN0ZWQKPiBmbGFnIGlzIHNldCwgc2tpcCB0aGUgY2hpbGQu Cj4gLklQIDMuCj4gV2l0aCB0aGUgY2hpbGQncyBBQ0w6Cj4gLlJTIDQKPiAuSVAgMS4gNAoKcy8x Li9hKS8KCihpLmUuLCB1c2UgYSBkaWZmZXJlbnQgbGFiZWxpbmcgc2NoZW1lIGZvciB0aGUgc3Vi bGlzdCkKCj4gSWYgdGhlCj4gLkIgZGVmYXVsdGVkCj4gZmxhZyBpcyBzZXQsIHJlcGxhY2UgdGhl IEFDTCB3aXRoIGFuIGVtcHR5IEFDTAo+IHdpdGggdGhlCj4gLkIgYXV0b19pbmhlcml0Cj4gZmxh ZyBzZXQuCj4gLklQIDIuCgpzLzIuL2IpLwoKPiBEZWxldGUgYWxsIGVudHJpZXMgd2hpY2ggaGF2 ZSB0aGUKPiAuQiBpbmhlcml0ZWQKPiBmbGFnIHNldC4KPiAuSVAgMy4KCnMvMy4vYykvCgo+IEFw cGVuZCBhbGwgZW50cmllcyBpbmhlcml0ZWQgZnJvbSB0aGUgcGFyZW50IGRpcmVjdG9yeSBhY2Nv cmRpbmcgdG8gc3RlcCAxIG9mCj4gdGhlIGFsZ29yaXRobSBkZXNjcmliZWQgdW5kZXIKPiAuSVIg IlBlcm1pc3Npb25zIEF0IEZpbGUgQ3JlYXRlIFRpbWUiLgo+IFNldCB0aGUKPiAuQiBpbmhlcml0 ZWQKPiBmbGFnIG9mIGVhY2ggb2YgdGhlc2UgZW50cmllcy4KPiAuSVAgNC4KCnMvNC4vZCkvCgo+ IFJlY29tcHV0ZSB0aGUgZmlsZSBtYXNrcy4KPiAuUkUKPiAuSVAgNC4KPiBJZiB0aGUgY2hpbGQg aXMgYSBkaXJlY3RvcnksIHJlY3Vyc2l2ZWx5IGFwcGx5IHRoaXMgYWxnb3JpdGhtLgo+IAo+IC5T SCBBQ0NFU1MgQ0hFQ0sgQUxHT1JJVEhNCj4gCj4gV2hlbiBhIHByb2Nlc3MgcmVxdWVzdHMgYSBw YXJ0aWN1bGFyIGtpbmQgb2YgYWNjZXNzIHRvIGEgZmlsZSBkZWZpbmVkIGJ5IGEgc2V0CgpzL2Rl ZmluZWQvcHJvdGVjdGVkLyAoPykKCj4gb2YgcmljaGFjbCBwZXJtaXNzaW9ucywgdGhlIGZvbGxv d2luZyBhbGdvcml0aG0gZGV0ZXJtaW5lcyBpZiB0aGUgYWNjZXNzIGlzCgpzL2lmL3doZXRoZXIv Cgo+IGdyYW50ZWQgb3IgZGVuaWVkOgo+IAo+IC5JUCAxLiA0Cj4gSWYgdGhlCj4gLkIgbWFza2Vk Cj4gQUNMIGZsYWcgaXMgc2V0LCB0aGVuOgo+IC5SUyA0Cj4gLklQIDEuIDQKCnMvMS4vYSkvCgpV c2UgYSBkaWZmZXJlbnQgbnVtYmVyaW5nIHNjaGVtZSBmb3Igc3VibGlzdHMuCgo+IGlmIHRoZQoK cy9pZi9JZi8KCj4gLkIgd3JpdGVfdGhyb3VnaAo+IEFDTCBmbGFnIGlzIHNldCwgdGhlbjoKPiAu UlMgNAo+IC5JUCBcKGJ1IDQKPiBpZiB0aGUgcmVxdWVzdGluZyBwcm9jZXNzIGlzIHRoZSBmaWxl IG93bmVyLCB0aGVuIGFjY2VzcyBpcyBncmFudGVkIGlmIHRoZQoKcy9pZi9JZi8KCj4gb3duZXIg bWFzayBpbmNsdWRlcyB0aGUgcmVxdWVzdGVkIHBlcm1pc3Npb25zLCBhbmQgaXMgb3RoZXJ3aXNl IGRlbmllZC4KPiAuSVAgXChidQo+IGlmIHRoZSByZXF1ZXN0aW5nIHByb2Nlc3MgaXMgbm90IHRo ZSBmaWxlIG93bmVyLCBpcyBub3QgaW4gdGhlIG93bmluZyBncm91cCwKCnMvaWYvSWYvCgo+IGFu ZCBubyBBQ0wgZW50cmllcyBvdGhlciB0aGFuCj4gLkIgZXZlcnlvbmVACj4gbWF0Y2ggdGhlIHBy b2Nlc3MsIHRoZW4gYWNjZXNzIGlzIGdyYW50ZWQgaWYgdGhlIG90aGVyIG1hc2sgaW5jbHVkZXMg dGhlCj4gcmVxdWVzdGVkIHBlcm1pc3Npb25zLCBhbmQgaXMgb3RoZXJ3aXNlIGRlbmllZC4KPiAu UkUKPiAuSVAgMi4KCnMvMi4vYikvCgo+IGlmIGFueSBvZiB0aGUgZm9sbG93aW5nIGlzIHRydWU6 CgpzL2lmL0lmLwoKPiAuUlMgNAo+IC5JUCBcKGJ1IDQKPiB0aGUgcmVxdWVzdGluZyBwcm9jZXNz IGlzIHRoZSBmaWxlIG93bmVyIGFuZCB0aGUgb3duZXIgbWFzayBkb2VzIG5vIGluY2x1ZGUgYWxs CgpzL25vIC9ub3QgLwoKPiByZXF1ZXN0ZWQgcGVybWlzc2lvbnMsCj4gLklQIFwoYnUgNAo+IHRo ZSByZXF1ZXN0aW5nIHByb2Nlc3MgaXMgbm90IHRoZSBmaWxlIG93bmVyIGFuZCBpdCBpcyBpbiB0 aGUgb3duaW5nIGdyb3VwIG9yCj4gbWF0Y2hlcyBhbnkgQUNMIGVudHJpZXMgb3RoZXIgdGhhbgo+ IC5CUiBldmVyeW9uZUAgLAo+IGFuZCB0aGUgZ3JvdXAgbWFzayBkb2VzIG5vIGluY2x1ZGUgYWxs IHJlcXVlc3RlZCBwZXJtaXNzaW9ucywKPiAuSVAgXChidSA0Cj4gdGhlIHJlcXVlc3RpbmcgcHJv Y2VzcyBpcyBub3QgdGhlIGZpbGUgb3duZXIsIG5vdCBpbiB0aGUgb3duaW5nIGdyb3VwLCBpdAo+ IG1hdGNoZXMgbm8gQUNMIGVudHJpZXMgb3RoZXIgdGhhbgo+IC5CUiBldmVyeW9uZUAgLAo+IGFu ZCB0aGUgb3RoZXIgbWFzayBkb2VzIG5vIGluY2x1ZGUgYWxsIHJlcXVlc3RlZCBwZXJtaXNzaW9u cywKPiAuUFAKPiB0aGVuIGFjY2VzcyBpcyBkZW5pZWQuCj4gLlJFCj4gLlJFCj4gLklQIDIuCj4g U2V0IHRoZSByZW1haW5pbmcgcGVybWlzc2lvbnMgdG8gdGhlIHJlcXVlc3RlZCBwZXJtaXNzaW9u cy4gIEdvIHRocm91Z2ggYWxsIEFDTAo+IGVudHJpZXMuIEZvciBlYWNoIGVudHJ5Ogo+IC5SUyA0 Cj4gLklQIDEuIDQKCnMvMS4vYSkvCgpVc2UgYSBkaWZmZXJlbnQgbnVtYmVyaW5nIHNjaGVtZSBm b3Igc3VibGlzdHMuCgo+IGlmIHRoZQo+IC5CIGluaGVyaXRfb25seQo+IG9yCj4gLkIgdW5tYXBw ZWQKPiBmbGFncyBhcmUgc2V0LCBjb250aW51ZSB3aXRoIHRoZSBuZXh0IEFDTCBlbnRyeS4KPiAu SVAgMi4KCnMvMi4vYikvCgo+IGlmIGFueSBvZiB0aGUgZm9sbG93aW5nIGlzIHRydWU6Cj4gLlJT IDQKPiAuSVAgXChidSA0Cj4gdGhlIGVudHJ5J3MgaWRlbnRpZmllciBpcwo+IC5CIG93bmVyQAo+ IGFuZCB0aGUgcmVxdWVzdGluZyBwcm9jZXNzIGlzIHRoZSBmaWxlIG93bmVyLAo+IC5JUCBcKGJ1 Cj4gdGhlIGVudHJ5J3MgaWRlbnRpZmllciBpcwo+IC5CIGdyb3VwQAo+IGFuZCB0aGUgcmVxdWVz dGluZyBwcm9jZXNzIGlzIGluIHRoZSBvd25pbmcgZ3JvdXAsCj4gLklQIFwoYnUKPiB0aGUgZW50 cnkncyBpZGVudGlmaWVyIGlzIGEgdXNlciBhbmQgdGhlIHJlcXVlc3RpbmcgcHJvY2VzcyBpcyBv d25lZCBieSB0aGF0Cj4gdXNlciwKPiAuSVAgXChidQo+IHRoZSBlbnRyeSdzIGlkZW50aWZpZXIg aXMgYSBncm91cCBhbmQgdGhlIHJlcXVlc3RpbmcgcHJvY2VzcyBpcyBhIG1lbWJlciBpbgo+IHRo YXQgZ3JvdXAsCj4gLklQIFwoYnUKPiB0aGUgZW50cnkncyBpZGVudGlmaWVyIGlzCj4gLkJSIGV2 ZXJ5b25lQCAsCj4gLlBQCj4gdGhlIGVudHJ5IG1hdGNoZXMgdGhlIHByb2Nlc3M7IHByb2NlZWQu IE90aGVyd2lzZSwgY29udGludWUgd2l0aCB0aGUgbmV4dCBBQ0wKCnMvcHJvY2VlZC9wcm9jZWVk IHRvIHRoZSBuZXh0IHN0ZXAvICAoPykKCj4gZW50cnkuCj4gLlJFCj4gLklQIDMuCgpzLzMuL2Mp LwoKPiBJZiB0aGUgZW50cnkgZGVuaWVzIGFueSBvZiB0aGUgcmVtYWluaW5nIHBlcm1pc3Npb25z LCBhY2Nlc3MgaXMgZGVuaWVkLgo+IC5JUCA0LgoKcy80Li9kKS8KCj4gSWYgdGhlIGVudHJ5IGFs bG93cyBhbnkgb2YgdGhlIHJlbWFpbmluZyBwZXJtaXNzaW9ucywgdGhlbjoKPiAuUlMgNAo+IC5J UCBcKGJ1IDQKPiBpZiB0aGUKPiAuQiBtYXNrZWQKPiBBQ0wgZmxhZyBpcyBzZXQgYW5kIHRoZSBl bnRyeSdzIGlkZW50aWZpZXIgaXMgbm90Cj4gLkIgb3duZXJACj4gb3IKPiAuQlIgZXZlcnlvbmVA Cj4gb3IgaXMgYSB1c2VyIGVudHJ5IG1hdGNoaW5nIHRoZSBmaWxlIG93bmVyLCByZW1vdmUgYWxs IHBlcm1pc3Npb25zIGZyb20gdGhlCj4gcmVtYWluaW5nIHBlcm1pc3Npb25zIHdoaWNoIGFyZSBi b3RoIGFsbG93ZWQgYnkgdGhlIGVudHJ5IGFuZCBpbmNsdWRlZCBpbiB0aGUKPiBncm91cCBtYXNr LAo+IC5JUCBcKGJ1Cj4gb3RoZXJ3aXNlLCByZW1vdmUgYWxsIHBlcm1pc3Npb25zIGZyb20gdGhl IHJlbWFpbmluZyBwZXJtaXNzaW9ucyB3aWNoIGFyZQo+IGFsbG93ZWQgYnkgdGhlIGVudHJ5Lgo+ IC5SRQo+IC5SRQo+IC5JUCAzLgo+IElmIHRoZXJlIGFyZSBubyBtb3JlIHJlbWFpbmluZyBwZXJt aXNzaW9ucywgYWNjZXNzIGlzIGFsbG93ZWQuIE90aGVyd2lzZSwKPiBhY2Nlc3MgaXMgZGVuaWVk Lgo+IAo+IC5TSCBDT01QVVRJTkcgVEhFIE1BWElNVU0gRklMRSBNQVNLUwo+IFdoZW4gc2V0dGlu ZyBhbiBBQ0wgYW5kIG5vIGZpbGUgbWFza3MgaGF2ZSBiZWVuIGV4cGxpY2l0bHkgc3BlY2lmaWVk IGFuZCB3aGVuCj4gaW5oZXJpdGluZyBhbiBBQ0wgZnJvbSB0aGUgcGFyZW50IGRpcmVjdG9yeSwg dGhlIGZvbGxvd2luZyBhbGdvcml0aG0gaXMgdXNlZAo+IGZvciBjb21wdXRpbmcgdGhlIGZpbGUg bWFza3M6Cj4gCj4gLklQIDEuIDQKPiBDbGVhciB0aGUgb3duZXIsIGdyb3VwLCBhbmQgb3RoZXIg ZmlsZSBtYXNrcy4gUmVtZW1iZXIgd2hpY2ggcGVybWlzc2lvbnMgaGF2ZQo+IGFscmVhZHkgYmVl biBwcm9jZXNzZWQgKGluaXRpYWxseSwgdGhlIGVtcHR5IHNldCkuCj4gLklQIDIuCj4gRm9yIGVh Y2ggQUNMIGVudHJ5Ogo+IC5SUyA0Cj4gLklQIFwoYnUgNAo+IElmIHRoZQo+IC5CIGluaGVyaXRf b25seQo+IGZsYWcgaXMgc2V0LCBza2lwIHRoZSBlbnRyeS4KPiAuSVAgXChidSA0Cj4gT3RoZXJ3 aXNlLCBjb21wdXRlIHdoaWNoIHBlcm1pc3Npb25zIHRoZSBlbnRyeSBhbGxvd3Mgb3IgZGVuaWVz IHRoYXQgaGF2ZSBub3QKPiBiZWVuIHByb2Nlc3NlZCB5ZXQgKHRoZSByZW1haW5pbmcgcGVybWlz c2lvbnMpLgo+IC5JUCBcKGJ1Cj4gSWYgdGhlIGVudHJ5IGlzIGFuCj4gLkIgb3duZXJACj4gZW50 cnksIGFkZCB0aGUgcmVtYWluaW5nIHBlcm1pc3Npb25zIHRvIHRoZSBvd25lciBtYXNrIGZvcgo+ IC5CIGFsbG93Cj4gZW50cmllcywgYW5kIHJlbW92ZSB0aGUgcmVtYWluaW5nIHBlcm1pc3Npb25z IGZyb20gdGhlIG93bmVyIG1hc2sgZm9yCj4gLkIgZGVueQo+IGVudHJpZXMuCj4gLklQIFwoYnUK PiBPdGhlcndpc2UsIGlmIHRoZSBlbnRyeSBpcyBhbgo+IC5CIGV2ZXJ5b25lQAo+IGVudHJ5LCBw cm9jZWVkIGFzIHdpdGgKPiAuQiBvd25lckAKPiBlbnRyaWVzIGJ1dCBhZGQgb3IgcmVtb3ZlIHRo ZSByZW1haW5pbmcgcGVybWlzc2lvbnMgZnJvbSB0aGUgb3duZXIsIGdyb3VwLCBhbmQKPiBvdGhl ciBmaWxlIG1hc2tzLgo+IC5JUCBcKGJ1Cj4gT3RoZXJ3aXNlLCBwcm9jZWVkIGFzIHdpdGgKPiAu QiBvd25lckAKPiBlbnRyaWVzIGJ1dCBhZGQgb3IgcmVtb3ZlIHRoZSByZW1haW5pbmcgcGVybWlz c2lvbnMgZnJvbSB0aGUgb3duZXIgYW5kIGdyb3VwCj4gZmlsZSBtYXNrcy4KPiAuSVAgXChidQo+ IEFkZCB0aGUgZW50cnkncyBwZXJtaXNzaW9ucyB0byB0aGUgcHJvY2Vzc2VkIHBlcm1pc3Npb25z Lgo+IC5SRQo+IC5QUAo+IFRoZSByZXN1bHRpbmcgZmlsZSBtYXNrcyByZXByZXNlbnQgdGhlIEFD TCBhcyBjbG9zZWx5IGFzIHBvc3NpYmxlLiBXaXRoIHRoZXNlCj4gZmlsZSBtYXNrcywgaWYgdGhl Cj4gLkIgbWFza2VkCj4gQUNMIGZsYWcgaXMgc2V0LCB0aGUgZWZmZWN0aXZlIHBlcm1pc3Npb25z IHN0aWxsIHN0YXkgdGhlIHNhbWUuCgpUaGlzIHBhZ2UgaXMgaW4gKmRlc3BlcmF0ZSogbmVlZCBv ZiAqbXVsdGlwbGUqIGV4YW1wbGVzLCBzdGFydGluZyBzaW1wbGUsCmFuZCBidWlsZGluZyB1cCBp biBjb21wbGV4aXR5LCB3aXRoIHdhbGt0aG9naCB0ZXh0IGV4cGxhaW5pbmcgaG93IHRoZQpwZXJt aXNzc2lvbnMgYXJlIGludGVycHJldGVkIGFuZCBob3cgdGhlIG1hc2tzIGFyZSBnZW5lcmF0ZWQu CkhhdmluZyByZWFkIHRoZSBwYWdlIG11bHRpcGxlIHRpbWVzIChhbmQgaGF2aW5nIGxpdHRsZSBr bm93bGVkZ2UKb2YgTkZTIEFDTHMpLCBJJ20gc3RpbGwgc3RydWdnbGluZyB0byBwdXQgYWxsIHRo ZSBwaWVjZXMgdG9nZXRoZXIuClByb2JhYmx5IHNvbWUgZXhhbXBsZXMgdGhhdCByZWxhdGUgdG8g YW4gTkZTIGNvbnRleHQgd291bGQgYWxzbyBiZQpoZWxwZnVsLgoKPiAuXCIgLlNIIEJVR1MKPiAu U0ggQVVUSE9SCj4gV3JpdHRlbiBieSBBbmRyZWFzIEdyw7xuYmFjaGVyIDxhZ3J1ZW5iYUByZWRo YXQuY29tPi4KPiAKPiBQbGVhc2Ugc2VuZCB5b3VyIGJ1ZyByZXBvcnRzLCBzdWdnZXN0ZWQgZmVh dHVyZXMgYW5kIGNvbW1lbnRzIHRvIHRoZSBhYm92ZSBhZGRyZXNzLgo+IAo+IC5TSCBDT05GT1JN SU5HIFRPCj4gUmljaCBBY2Nlc3MgQ29udHJvbCBMaXN0cyBhcmUgTGludXgtc3BlY2lmaWMuCj4g LlNIIFNFRSBBTFNPCj4gLkJSIGNobW9kICgxKSwKPiAuQlIgZ2V0cmljaGFjbCAoMSksCj4gLkJS IGxzICgxKSwKPiAuQlIgc2V0cmljaGFjbCAoMSkKPiAuQlIgc3RhdCAoMiksCj4gLkJSIHVtYXNr ICgyKSwKPiAuQlIgYWNsICg3KQo+IC5cIiBsaWJyaWNoYWNsCgpDaGVlcnMsCgpNaWNoYWVsCgoK LS0gCk1pY2hhZWwgS2VycmlzawpMaW51eCBtYW4tcGFnZXMgbWFpbnRhaW5lcjsgaHR0cDovL3d3 dy5rZXJuZWwub3JnL2RvYy9tYW4tcGFnZXMvCkxpbnV4L1VOSVggU3lzdGVtIFByb2dyYW1taW5n IFRyYWluaW5nOiBodHRwOi8vbWFuNy5vcmcvdHJhaW5pbmcvCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwp4ZnMgbWFpbGluZyBsaXN0Cnhmc0Bvc3Muc2dp LmNvbQpodHRwOi8vb3NzLnNnaS5jb20vbWFpbG1hbi9saXN0aW5mby94ZnMK