Older linux clients match the 'sec=' mount option flavor against the server's
flavor list (if available) and return EPERM if the specified flavor or AUTH_NULL
(which "matches" any flavor) is not found.
Recent changes skip this step and allow the vfs mount even though no operations
will succeed, creating a 'dud' mount.
This patch reverts back to the old behavior of matching specified flavors
against the server list and also returns EPERM when no sec= is specified and
none of the flavors returned by the server are supported by the client.
Example of behavior change:
the server's /etc/exports:
/export/krb5 *(sec=krb5,rw,no_root_squash)
old client behavior:
$ uname -a
Linux one.apikia.fake 3.8.8-202.fc18.x86_64 #1 SMP Wed Apr 17 23:25:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
mount.nfs: timeout set for Sun May 5 17:32:04 2013
mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting zero:/export/krb5
recently changed behavior:
$ uname -a
Linux one.apikia.fake 3.9.0-testing+ #2 SMP Fri May 3 20:29:32 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
$ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
mount.nfs: timeout set for Sun May 5 17:37:17 2013
mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
$ ls /mnt
ls: cannot open directory /mnt: Permission denied
$ sudo ls /mnt
ls: cannot open directory /mnt: Permission denied
$ sudo df /mnt
df: ‘/mnt’: Permission denied
df: no file systems processed
$ sudo umount /mnt
$
Signed-off-by: Weston Andros Adamson <[email protected]>
---
V3 - change EPERM to EACCES
fs/nfs/super.c | 37 ++++++++++++++++++++++++++++++-------
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index eb494f6..f16a4b3 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1611,14 +1611,12 @@ out_security_failure:
* Select a security flavor for this mount. The selected flavor
* is planted in args->auth_flavors[0].
*/
-static void nfs_select_flavor(struct nfs_parsed_mount_data *args,
+static int nfs_select_flavor(struct nfs_parsed_mount_data *args,
struct nfs_mount_request *request)
{
unsigned int i, count = *(request->auth_flav_len);
rpc_authflavor_t flavor;
-
- if (args->auth_flavors[0] != RPC_AUTH_MAXFLAVOR)
- goto out;
+ bool auth_null_seen = false;
/*
* The NFSv2 MNT operation does not return a flavor list.
@@ -1634,6 +1632,21 @@ static void nfs_select_flavor(struct nfs_parsed_mount_data *args,
goto out_default;
/*
+ * If the sec= mount option is used, the specified flavor or AUTH_NULL
+ * must be in the list returned by the server.
+ */
+ if (args->auth_flavors[0] != RPC_AUTH_MAXFLAVOR) {
+ for (i = 0; i < count; i++) {
+ if (args->auth_flavors[0] == request->auth_flavs[i] ||
+ request->auth_flavs[i] == RPC_AUTH_NULL)
+ goto out;
+ }
+ dfprintk(MOUNT, "NFS: auth flavor %d not supported server\n",
+ args->auth_flavors[0]);
+ goto out_err;
+ }
+
+ /*
* RFC 2623, section 2.7 suggests we SHOULD prefer the
* flavor listed first. However, some servers list
* AUTH_NULL first. Avoid ever choosing AUTH_NULL.
@@ -1646,6 +1659,7 @@ static void nfs_select_flavor(struct nfs_parsed_mount_data *args,
case RPC_AUTH_UNIX:
goto out_set;
case RPC_AUTH_NULL:
+ auth_null_seen = true;
continue;
default:
if (rpcauth_get_gssinfo(flavor, &info) == 0)
@@ -1653,12 +1667,22 @@ static void nfs_select_flavor(struct nfs_parsed_mount_data *args,
}
}
+ if (!auth_null_seen) {
+ dfprintk(MOUNT, "NFS: no auth flavors in common with server\n");
+ goto out_err;
+ }
+
out_default:
- flavor = RPC_AUTH_UNIX;
+ /* use default if flavor not already set */
+ flavor = (args->auth_flavors[0] == RPC_AUTH_MAXFLAVOR) ?
+ RPC_AUTH_UNIX : args->auth_flavors[0];
out_set:
args->auth_flavors[0] = flavor;
out:
dfprintk(MOUNT, "NFS: using auth flavor %d\n", args->auth_flavors[0]);
+ return 0;
+out_err:
+ return -EACCES;
}
/*
@@ -1721,8 +1745,7 @@ static int nfs_request_mount(struct nfs_parsed_mount_data *args,
return status;
}
- nfs_select_flavor(args, &request);
- return 0;
+ return nfs_select_flavor(args, &request);
}
struct dentry *nfs_try_mount(int flags, const char *dev_name,
--
1.7.12.4 (Apple Git-37)
On May 6, 2013, at 3:43 PM, "Myklebust, Trond" <[email protected]> wrote:
> On Mon, 2013-05-06 at 15:41 -0400, Weston Andros Adamson wrote:
>> Older linux clients match the 'sec=' mount option flavor against the server's
>> flavor list (if available) and return EPERM if the specified flavor or AUTH_NULL
>> (which "matches" any flavor) is not found.
>>
>> Recent changes skip this step and allow the vfs mount even though no operations
>> will succeed, creating a 'dud' mount.
>>
>> This patch reverts back to the old behavior of matching specified flavors
>> against the server list and also returns EPERM when no sec= is specified and
>> none of the flavors returned by the server are supported by the client.
>>
>> Example of behavior change:
>>
>> the server's /etc/exports:
>>
>> /export/krb5 *(sec=krb5,rw,no_root_squash)
>>
>> old client behavior:
>>
>> $ uname -a
>> Linux one.apikia.fake 3.8.8-202.fc18.x86_64 #1 SMP Wed Apr 17 23:25:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>> $ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
>> mount.nfs: timeout set for Sun May 5 17:32:04 2013
>> mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
>> mount.nfs: prog 100003, trying vers=3, prot=6
>> mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
>> mount.nfs: prog 100005, trying vers=3, prot=17
>> mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
>> mount.nfs: mount(2): Permission denied
>> mount.nfs: access denied by server while mounting zero:/export/krb5
>>
>> recently changed behavior:
>>
>> $ uname -a
>> Linux one.apikia.fake 3.9.0-testing+ #2 SMP Fri May 3 20:29:32 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
>> $ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
>> mount.nfs: timeout set for Sun May 5 17:37:17 2013
>> mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
>> mount.nfs: prog 100003, trying vers=3, prot=6
>> mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
>> mount.nfs: prog 100005, trying vers=3, prot=17
>> mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
>> $ ls /mnt
>> ls: cannot open directory /mnt: Permission denied
>> $ sudo ls /mnt
>> ls: cannot open directory /mnt: Permission denied
>> $ sudo df /mnt
>> df: ?/mnt?: Permission denied
>> df: no file systems processed
>> $ sudo umount /mnt
>> $
>>
>> Signed-off-by: Weston Andros Adamson <[email protected]>
>> ---
>>
>> Version 2:
>> - now just uses specified flavor when:
>> - AUTH_NULL is in the server list
>> - flavor is in the server list
>>
>> - now returns EPERM when no sec= specified and no client supported flavors are
>> in the server list
>>
>
> Shouldn't that be EACCES?
Yes. I think both cases should be EACCES.
Will test and repost
-dros
>
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> [email protected]
> http://www.netapp.com
On May 6, 2013, at 11:34 AM, "Adamson, Dros" <[email protected]> wrote:
>
> On May 6, 2013, at 11:17 AM, Chuck Lever <[email protected]>
> wrote:
>
>>
>> On May 6, 2013, at 10:49 AM, "Adamson, Dros" <[email protected]> wrote:
>>
>>>
>>> On May 6, 2013, at 9:52 AM, Chuck Lever <[email protected]> wrote:
>>>
>>>> Hi-
>>>>
>>>> On May 6, 2013, at 9:27 AM, Weston Andros Adamson <[email protected]> wrote:
>>>>
>>>>> Older clients match the 'sec=' mount option flavor against the server's
>>>>> flavor list (if available) and return EPERM if the specified flavor is not
>>>>> found. Recent changes would skip this step and allow the vfs mount even
>>>>> though no operations will succeed.
>>>>>
>>>>> Signed-off-by: Weston Andros Adamson <[email protected]>
>>>>> ---
>>>>>
>>>>> Hey Chuck,
>>>>>
>>>>> This fixes a regression that was introduced with the recent nfs_select_flavor
>>>>> changes - I'm pretty sure we want to match the specified flavor instead of just
>>>>> using it.
>>>>>
>>>>> Example of the regression:
>>>>>
>>>>> the server's /etc/exports:
>>>>>
>>>>> /export/krb5 *(sec=krb5,sec=none,rw,no_root_squash)
>>>>>
>>>>> old client behavior:
>>>>>
>>>>> $ uname -a
>>>>> Linux one.apikia.fake 3.8.8-202.fc18.x86_64 #1 SMP Wed Apr 17 23:25:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>>>>> $ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
>>>>> mount.nfs: timeout set for Sun May 5 17:32:04 2013
>>>>> mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>> mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>> mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
>>>>> mount.nfs: mount(2): Permission denied
>>>>> mount.nfs: access denied by server while mounting zero:/export/krb5
>>>>
>>>> This is wrong behavior, and is fixed by my patch.
>>>>
>>>>> recently changed behavior:
>>>>>
>>>>> $ uname -a
>>>>> Linux one.apikia.fake 3.9.0-testing+ #2 SMP Fri May 3 20:29:32 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
>>>>> $ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
>>>>> mount.nfs: timeout set for Sun May 5 17:37:17 2013
>>>>> mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>> mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>> mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
>>>>> $ ls /mnt
>>>>> ls: cannot open directory /mnt: Permission denied
>>>>> $ sudo ls /mnt
>>>>> ls: cannot open directory /mnt: Permission denied
>>>>> $ sudo df /mnt
>>>>> df: ?/mnt?: Permission denied
>>>>> df: no file systems processed
>>>>> $ sudo umount /mnt
>>>>> $
>>>>
>>>> This is correct behavior. The server should map the user's AUTH_SYS credential to anonymous. If anonymous does not have permission on /export/krb5, then the server should prevent its access to the export.
>>>
>>> You're talking about AUTH_NULL behavior here, right?
>>>
>>>>
>>>> I assume this is a Linux NFS server. Does the Linux server support sec=none listed in the export options in the same way that NetApp and Oracle Solaris do?
>>>
>>>
>>> So there are two issues here and I think they're getting confused.
>>>
>>> The example is of the first issue: mounting a krb5 only export with sec=sys
>>> - client mounts sec=sys
>>> - the server list is [krb5]
>>> - the client completely ignores this list and just uses sys.
>>> - no operations work, it's a 'dud mount'
>>>
>>> The second issue is the AUTH_NULL stuff - lets just ignore that for now.
>>>
>>> Are you saying that the client should just use whatever sec= is specified and never try to match against the server list?
>>
>> That's what my patch does. The reason for this is that the server can interpret the mount's security flavor any way it likes.
>>
>> Perhaps we should take that fallback position only if the server lists AUTH_NULL in the flavor list. If AUTH_NULL is not listed, ensure the flavor requested on the mount command line is available on the server (the most recent previous behavior); fail if no matching flavor is found.
>>
>> If the mount command line does not specify a flavor, we could look in the server's list for a flavor we support, then fail if none is found.
>
> If I'm reading this right, that's what this patch does.
>
> - if no sec= is specified, we look through the servers list for a supported flavor (same behavior as without this patch).
If not found, return -EPERM.
> - if sec= is specified, check the server list
> - if flavor is found, use it
> - else if AUTH_NULL is in the list, just use the user specified sec= flavor
> - else return -EPERM
Unconditionally use the user's flavor if AUTH_NULL is in the list. So reverse the order of the first two checks.
> Also: if we don't get a server list for whatever reason, just use the specified sec= flavor.
Leave the first checks in nfs_select_flavor() intact, in other words.
>
> Does that sound right? If so, does the patch look good?
>
> -dros
>
>>
>>> A little background - I ran into this implementing a different patch that makes sure v4.x mounts are actually using the specified flavor (if one exists) to mount the export -- that is, it can follow SECINFOs to do initial lookup, but must be using the specified flavor on the export path passed to mount. After the initial mount lookup, SECINFOs will be used normally. Trond thought that this was a bug that should be fixed - that it's wrong when client reports that it's using one flavor (as seen in mount output, etc) when it's really using another. This (other) patch works, but when no version is specified, it always falls back to v3 and the mount will always succeed - even if the auth flavor isn't supported by the export.
>>>
>>> -dros
>>>
>>>
>>>>
>>>>> I also made an attempt to support "AUTH_NULL means the server will ignore the
>>>>> cred, so just use the specified flavor" behavior from much older kernels, but
>>>>> I'm not sure if we want this logic.
>>>>>
>>>>> I'd actually prefer getting rid of this AUTH_NULL logic, it's just that some
>>>>> older clients (RHEL 5, etc) would succeed in mounting when sec=sys specified,
>>>>> server list = [AUTH_NULL] (the client ends up sending AUTH_UNIX creds that are
>>>>> ignored by the server), while newer kernels do not. The workaround in newer
>>>>> kernels is to specify sec=none.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> -dros
>>>>>
>>>>> fs/nfs/super.c | 39 ++++++++++++++++++++++++++++++++-------
>>>>> 1 file changed, 32 insertions(+), 7 deletions(-)
>>>>>
>>>>> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
>>>>> index eb494f6..6476b5d 100644
>>>>> --- a/fs/nfs/super.c
>>>>> +++ b/fs/nfs/super.c
>>>>> @@ -1611,14 +1611,12 @@ out_security_failure:
>>>>> * Select a security flavor for this mount. The selected flavor
>>>>> * is planted in args->auth_flavors[0].
>>>>> */
>>>>> -static void nfs_select_flavor(struct nfs_parsed_mount_data *args,
>>>>> +static int nfs_select_flavor(struct nfs_parsed_mount_data *args,
>>>>> struct nfs_mount_request *request)
>>>>> {
>>>>> unsigned int i, count = *(request->auth_flav_len);
>>>>> rpc_authflavor_t flavor;
>>>>> -
>>>>> - if (args->auth_flavors[0] != RPC_AUTH_MAXFLAVOR)
>>>>> - goto out;
>>>>> + bool auth_null_seen = false;
>>>>>
>>>>> /*
>>>>> * The NFSv2 MNT operation does not return a flavor list.
>>>>> @@ -1634,6 +1632,26 @@ static void nfs_select_flavor(struct nfs_parsed_mount_data *args,
>>>>> goto out_default;
>>>>>
>>>>> /*
>>>>> + * If the sec= mount option is used, the flavor must be in the list
>>>>> + * returned by the server.
>>>>> + *
>>>>> + * One exception is when the server's flavor list includes AUTH_NULL:
>>>>> + * Some servers implement AUTH_NULL by completely ignoring the rpc
>>>>> + * cred, so the client can use any flavor.
>>>>> + */
>>>>> + if (args->auth_flavors[0] != RPC_AUTH_MAXFLAVOR) {
>>>>> + for (i = 0; i < count; i++) {
>>>>> + if (args->auth_flavors[0] == request->auth_flavs[i])
>>>>> + goto out;
>>>>> + if (request->auth_flavs[i] == RPC_AUTH_NULL)
>>>>> + auth_null_seen = true;
>>>>> + }
>>>>> + if (auth_null_seen)
>>>>> + goto out;
>>>>> + goto out_nomatch;
>>>>> + }
>>>>> +
>>>>> + /*
>>>>> * RFC 2623, section 2.7 suggests we SHOULD prefer the
>>>>> * flavor listed first. However, some servers list
>>>>> * AUTH_NULL first. Avoid ever choosing AUTH_NULL.
>>>>> @@ -1654,11 +1672,19 @@ static void nfs_select_flavor(struct nfs_parsed_mount_data *args,
>>>>> }
>>>>>
>>>>> out_default:
>>>>> - flavor = RPC_AUTH_UNIX;
>>>>> + /* use default if flavor not already set */
>>>>> + flavor = (args->auth_flavors[0] == RPC_AUTH_MAXFLAVOR) ?
>>>>> + RPC_AUTH_UNIX : args->auth_flavors[0];
>>>>> out_set:
>>>>> args->auth_flavors[0] = flavor;
>>>>> out:
>>>>> dfprintk(MOUNT, "NFS: using auth flavor %d\n", args->auth_flavors[0]);
>>>>> + return 0;
>>>>> +
>>>>> +out_nomatch:
>>>>> + dfprintk(MOUNT, "NFS: auth flavor %d not supported by server\n",
>>>>> + args->auth_flavors[0]);
>>>>> + return -EPERM;
>>>>> }
>>>>>
>>>>> /*
>>>>> @@ -1721,8 +1747,7 @@ static int nfs_request_mount(struct nfs_parsed_mount_data *args,
>>>>> return status;
>>>>> }
>>>>>
>>>>> - nfs_select_flavor(args, &request);
>>>>> - return 0;
>>>>> + return nfs_select_flavor(args, &request);
>>>>> }
>>>>>
>>>>> struct dentry *nfs_try_mount(int flags, const char *dev_name,
>>>>> --
>>>>> 1.7.12.4 (Apple Git-37)
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>> the body of a message to [email protected]
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>> --
>>>> Chuck Lever
>>>> chuck[dot]lever[at]oracle[dot]com
>>>>
>>>>
>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
T24gTW9uLCAyMDEzLTA1LTA2IGF0IDE1OjQxIC0wNDAwLCBXZXN0b24gQW5kcm9zIEFkYW1zb24g
d3JvdGU6DQo+IE9sZGVyIGxpbnV4IGNsaWVudHMgbWF0Y2ggdGhlICdzZWM9JyBtb3VudCBvcHRp
b24gZmxhdm9yIGFnYWluc3QgdGhlIHNlcnZlcidzDQo+IGZsYXZvciBsaXN0IChpZiBhdmFpbGFi
bGUpIGFuZCByZXR1cm4gRVBFUk0gaWYgdGhlIHNwZWNpZmllZCBmbGF2b3Igb3IgQVVUSF9OVUxM
DQo+ICh3aGljaCAibWF0Y2hlcyIgYW55IGZsYXZvcikgaXMgbm90IGZvdW5kLg0KPiANCj4gUmVj
ZW50IGNoYW5nZXMgc2tpcCB0aGlzIHN0ZXAgYW5kIGFsbG93IHRoZSB2ZnMgbW91bnQgZXZlbiB0
aG91Z2ggbm8gb3BlcmF0aW9ucw0KPiB3aWxsIHN1Y2NlZWQsIGNyZWF0aW5nIGEgJ2R1ZCcgbW91
bnQuDQo+IA0KPiBUaGlzIHBhdGNoIHJldmVydHMgYmFjayB0byB0aGUgb2xkIGJlaGF2aW9yIG9m
IG1hdGNoaW5nIHNwZWNpZmllZCBmbGF2b3JzDQo+IGFnYWluc3QgdGhlIHNlcnZlciBsaXN0IGFu
ZCBhbHNvIHJldHVybnMgRVBFUk0gd2hlbiBubyBzZWM9IGlzIHNwZWNpZmllZCBhbmQNCj4gbm9u
ZSBvZiB0aGUgZmxhdm9ycyByZXR1cm5lZCBieSB0aGUgc2VydmVyIGFyZSBzdXBwb3J0ZWQgYnkg
dGhlIGNsaWVudC4NCj4gDQo+IEV4YW1wbGUgb2YgYmVoYXZpb3IgY2hhbmdlOg0KPiANCj4gdGhl
IHNlcnZlcidzIC9ldGMvZXhwb3J0czoNCj4gDQo+IC9leHBvcnQva3JiNSAgICAgICooc2VjPWty
YjUscncsbm9fcm9vdF9zcXVhc2gpDQo+IA0KPiBvbGQgY2xpZW50IGJlaGF2aW9yOg0KPiANCj4g
JCB1bmFtZSAtYQ0KPiBMaW51eCBvbmUuYXBpa2lhLmZha2UgMy44LjgtMjAyLmZjMTgueDg2XzY0
ICMxIFNNUCBXZWQgQXByIDE3IDIzOjI1OjE3IFVUQyAyMDEzIHg4Nl82NCB4ODZfNjQgeDg2XzY0
IEdOVS9MaW51eA0KPiAkIHN1ZG8gbW91bnQgLXYgLW8gc2VjPXN5cyx2ZXJzPTMgemVybzovZXhw
b3J0L2tyYjUgL21udA0KPiBtb3VudC5uZnM6IHRpbWVvdXQgc2V0IGZvciBTdW4gTWF5ICA1IDE3
OjMyOjA0IDIwMTMNCj4gbW91bnQubmZzOiB0cnlpbmcgdGV4dC1iYXNlZCBvcHRpb25zICdzZWM9
c3lzLHZlcnM9MyxhZGRyPTE5Mi4xNjguMTAwLjEwJw0KPiBtb3VudC5uZnM6IHByb2cgMTAwMDAz
LCB0cnlpbmcgdmVycz0zLCBwcm90PTYNCj4gbW91bnQubmZzOiB0cnlpbmcgMTkyLjE2OC4xMDAu
MTAgcHJvZyAxMDAwMDMgdmVycyAzIHByb3QgVENQIHBvcnQgMjA0OQ0KPiBtb3VudC5uZnM6IHBy
b2cgMTAwMDA1LCB0cnlpbmcgdmVycz0zLCBwcm90PTE3DQo+IG1vdW50Lm5mczogdHJ5aW5nIDE5
Mi4xNjguMTAwLjEwIHByb2cgMTAwMDA1IHZlcnMgMyBwcm90IFVEUCBwb3J0IDIwMDQ4DQo+IG1v
dW50Lm5mczogbW91bnQoMik6IFBlcm1pc3Npb24gZGVuaWVkDQo+IG1vdW50Lm5mczogYWNjZXNz
IGRlbmllZCBieSBzZXJ2ZXIgd2hpbGUgbW91bnRpbmcgemVybzovZXhwb3J0L2tyYjUNCj4gDQo+
IHJlY2VudGx5IGNoYW5nZWQgYmVoYXZpb3I6DQo+IA0KPiAkIHVuYW1lIC1hDQo+IExpbnV4IG9u
ZS5hcGlraWEuZmFrZSAzLjkuMC10ZXN0aW5nKyAjMiBTTVAgRnJpIE1heSAzIDIwOjI5OjMyIEVE
VCAyMDEzIHg4Nl82NCB4ODZfNjQgeDg2XzY0IEdOVS9MaW51eA0KPiAkIHN1ZG8gbW91bnQgLXYg
LW8gc2VjPXN5cyx2ZXJzPTMgemVybzovZXhwb3J0L2tyYjUgL21udA0KPiBtb3VudC5uZnM6IHRp
bWVvdXQgc2V0IGZvciBTdW4gTWF5ICA1IDE3OjM3OjE3IDIwMTMNCj4gbW91bnQubmZzOiB0cnlp
bmcgdGV4dC1iYXNlZCBvcHRpb25zICdzZWM9c3lzLHZlcnM9MyxhZGRyPTE5Mi4xNjguMTAwLjEw
Jw0KPiBtb3VudC5uZnM6IHByb2cgMTAwMDAzLCB0cnlpbmcgdmVycz0zLCBwcm90PTYNCj4gbW91
bnQubmZzOiB0cnlpbmcgMTkyLjE2OC4xMDAuMTAgcHJvZyAxMDAwMDMgdmVycyAzIHByb3QgVENQ
IHBvcnQgMjA0OQ0KPiBtb3VudC5uZnM6IHByb2cgMTAwMDA1LCB0cnlpbmcgdmVycz0zLCBwcm90
PTE3DQo+IG1vdW50Lm5mczogdHJ5aW5nIDE5Mi4xNjguMTAwLjEwIHByb2cgMTAwMDA1IHZlcnMg
MyBwcm90IFVEUCBwb3J0IDIwMDQ4DQo+ICQgbHMgL21udA0KPiBsczogY2Fubm90IG9wZW4gZGly
ZWN0b3J5IC9tbnQ6IFBlcm1pc3Npb24gZGVuaWVkDQo+ICQgc3VkbyBscyAvbW50DQo+IGxzOiBj
YW5ub3Qgb3BlbiBkaXJlY3RvcnkgL21udDogUGVybWlzc2lvbiBkZW5pZWQNCj4gJCBzdWRvIGRm
IC9tbnQNCj4gZGY6IOKAmC9tbnTigJk6IFBlcm1pc3Npb24gZGVuaWVkDQo+IGRmOiBubyBmaWxl
IHN5c3RlbXMgcHJvY2Vzc2VkDQo+ICQgc3VkbyB1bW91bnQgL21udA0KPiAkDQo+IA0KPiBTaWdu
ZWQtb2ZmLWJ5OiBXZXN0b24gQW5kcm9zIEFkYW1zb24gPGRyb3NAbmV0YXBwLmNvbT4NCj4gLS0t
DQo+IA0KPiBWZXJzaW9uIDI6DQo+ICAtIG5vdyBqdXN0IHVzZXMgc3BlY2lmaWVkIGZsYXZvciB3
aGVuOg0KPiAgICAtIEFVVEhfTlVMTCBpcyBpbiB0aGUgc2VydmVyIGxpc3QNCj4gICAgLSBmbGF2
b3IgaXMgaW4gdGhlIHNlcnZlciBsaXN0DQo+IA0KPiAgLSBub3cgcmV0dXJucyBFUEVSTSB3aGVu
IG5vIHNlYz0gc3BlY2lmaWVkIGFuZCBubyBjbGllbnQgc3VwcG9ydGVkIGZsYXZvcnMgYXJlDQo+
ICAgIGluIHRoZSBzZXJ2ZXIgbGlzdA0KPiANCg0KU2hvdWxkbid0IHRoYXQgYmUgRUFDQ0VTPw0K
DQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5l
dEFwcA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQo=