139411 2006-07-06 05:00 0000 chown utility looks up numeric ids which causes hang in bootmisc with "chown 0:0" 2006-08-08 17:02:27 0000 1 1 1 Unclassified Gentoo Linux Core system 2006.0 All Linux RESOLVED FIXED P2 critical --- 1 torsten@tk-webart.de base-system@gentoo.org gfa@zumbi.com.ar Jimmy.Jazz@gmx.net mstockin@gmx.net torsten@tk-webart.de 2006-07-06 05:00:41 0000 Hi there, I have a reproducable bug that already occurred on two of my x86 servers: /etc/init.d/bootmisc as found in sys-apps/baselayout-1.12.1 hangs on boot in line 115, while doing chown 0:0 /tmp/.{ICE,X11}-unix It's possible to continue the boot process by pressing <ctrl>-c, but that shouldn't be a permanent solution. I just wonder, if this line is really necessary. The X11 directories are freshly created on wipe as well as on clean, and during the boot process, this is obviously done by root, thus by uid:gid 0:0. Why then this chown anyway? Looking forward to be enlightened Torsten vapier@gentoo.org 2006-07-06 17:00:03 0000 if a simple chown is hanging, you've got bigger problems the chown/chmod are sanity checks to make sure we have correct permissions, just like the comment says above the code i'd suggest you drop the redirect to /dev/null and see if you get any errors ... if not, try adding `strace` before the chown call and see wtf is going on torsten@tk-webart.de 2006-07-07 03:42:06 0000 Thanks for the tipp, strace indeed revealed the problem - and it's not a trivial one: We use an LDAP directory coupled with a kerberos V password database for authentication of "normal" users against Linux. The nsswitch.conf thus looks as follows: passwd: compat files ldap shadow: compat files ldap group: compat files ldap In addition there are pam_ldap and pam_krb5 installed - and called by /etc/pam.d/system-auth strace shows that chown 0:0 looks for the LDAP entries, but since there are no network interfaces up, it tries indefinetely to resolve the hostname of the LDAP server. A trivial solution seams to be to substitute chown 0:0 by chown root:root Don't ask me, why chown reacts that allergic to numeric IDs. Anyway, chown root:root seems pretty valid to me (a standard Linux system without a user "root" wouldn't be able to run anything, not even speaking of X11), so can it go to baselayout, please? Torsten vapier@gentoo.org 2006-07-07 15:01:14 0000 we use 0:0 because of stupid *BSD systems that map the root group to gid 10 and the wheel group to gid 0 seems odd that numeric id's are looked up in the database though ... is there a case where this would make sense (i cant think of one) ? torsten@tk-webart.de 2006-07-09 03:48:12 0000 Ouch, *BSD - yes I know the problem with groups. Have two FreeBSD servers running myself. I also don't know, why numeric IDs are looked up and named ones not. I guess, there's something wrong with the way, nss_ldap handles numeric IDs. There was a revision bump lately, maybe the error lies there. Question is, whether it depends on one of the patches applied in the nss_ldap ebuild, or whether the good folks at PADL software built the sh*t directly into their software. I will examine that further on monday. torsten@tk-webart.de 2006-07-11 02:33:58 0000 I somehow narrowed the problem down. The standard bootmisc works smoothly up to sys-auth/nss_ldap-2.39-r1 The next version in portage is: sys-auth/nss_ldap-2.49 And this one as well as all following ones tries to resolve the numeric IDs. My knowledge of C is insufficient to see what leads to that change, so perhaps someone else should have a look... vapier@gentoo.org 2006-07-14 21:28:16 0000 np, we have a dev who "loves" this package ;) robbat2@gentoo.org 2006-07-17 18:56:40 0000 vapier: I'm looking at it, but could you also please look at coreutils for chown? By default it does a getpwnam/getgrnam on the arguments that are passed in. If this fails (returning NULL instead of a pointer to a struct), they try to convert the argument to a numeric value. I'm interested if this behavior has always been this way? The getpwnam/getgrnam would always go to your configured NSS source, so this may be a repeat of the lookup delay issues: Torston: could you please try nss_ldap-250-r1 and see EXACTLY how long the delays are? (250-r1 changes the timeout behavior of nss_ldap on purpose). In 249, it shouldn't actually be a hang, but a very long timeout (nearly 5 minutes for each lookup). torsten@tk-webart.de 2006-07-20 04:13:30 0000 Ok, boys, I measured the timeouts. They appear to be exactly 30 seconds with 250-r1. That's indeed not a very long time compared to BIOS posts, SCSI-detection, etc... Anyway, there must be a way to keep nss_ldap from even looking if there is none of the network devices up yet (which is definitely the case during that early boot stage) robbat2@gentoo.org 2006-07-20 08:56:12 0000 ok, if they are 30 seconds with 250-r1, then they were definetly significently longer on older versions. spanky: in chown from coreutils, could the logic possibly be changed to see that the passed in value is numeric instead of trying to look it up and only after that fails converting to numeric? The file you'd need to change is ${S}/lib/userparse.c Torsten: the problem is that you can't differentiate between the remote LDAP server being totally down, and the local network being down. Both cases are the same effective error returned to Linux. robbat2@gentoo.org 2006-08-03 11:29:47 0000 *** Bug 142626 has been marked as a duplicate of this bug. *** robbat2@gentoo.org 2006-08-03 12:19:30 0000 base-system: please read the summary below, and fix coreutils asap. I was asked why this doesn't seem to behave. here's a short summary of what happens: 1. user calls 'chown 0:0 foo' 2. chown splits this into two STRINGS, user="0", group="0" 3. chown (via some code in the lib/ portion of coreutils), does getpwnam("0"), getgrnam("0"). 4. this causes NSS to go and look for a user and group with a NAME of "0". Notice not a number of zero, but a string name of "0". 5. NSS checks files for a user/group named "0". Finds nothing. 6. NSS checks ldap for a user/group named "0". LONG delay happens here because the LDAP server (if local) is not yet started or (if remote) is not yet accessible (networking isn't up). 7. chown code decides that if nothing was found so far, try to convert it to a number. This succeeds, and the chown is actually done at this point. #7 needs to move way up, to realize that the input is a numeric value, and not a string, and should not be looked up at a name. Jimmy.Jazz@gmx.net 2006-08-03 16:02:48 0000 (In reply to comment #11) I agree with your conclusion but upgrading nss_ldap didn't give any improvement :( As you asked me to upgrade to nss_ldap-250-r1 and time the exact delay until the ldap request timed out, i'm able to confirm the delay for the lookup is ... longer than 30 minutes. That is further then the 30 seconds awaited. Tired to wait for a none coming response, i finally stopped the process. So, chown has never returned and you will certainly be disappointed by the following result: + mkdir -p /tmp/.ICE-unix /tmp/.X11-unix + date jeu ao Jimmy.Jazz@gmx.net 2006-08-03 16:02:48 0000 (In reply to comment #11) I agree with your conclusion but upgrading nss_ldap didn't give any improvement :( As you asked me to upgrade to nss_ldap-250-r1 and time the exact delay until the ldap request timed out, i'm able to confirm the delay for the lookup is ... longer than 30 minutes. That is further then the 30 seconds awaited. Tired to wait for a none coming response, i finally stopped the process. So, chown has never returned and you will certainly be disappointed by the following result: + mkdir -p /tmp/.ICE-unix /tmp/.X11-unix + date jeu aoû 3 21:10:54 MEST 2006 + chown 0:0 /tmp/.ICE-unix /tmp/.X11-unix Ctrl+c (30 minutes is really really time consuming :)) Moreover i didn't set the idle_timelimit in /etc/ldap.conf and let it simply to its default value (certainly 3600 seconds). Jj Jimmy.Jazz@gmx.net 2006-08-03 16:30:57 0000 (In reply to comment #11) It's late, it's time for me to go bed. Tomorrow is an other working day ;) I forgot to add the timings you mentioned so i did it in an other test but without more success. #cat /etc/ldap.conf ... nss_reconnect_tries 4 # number of times to double the sleep time nss_reconnect_sleeptime 1 # initial sleep value nss_reconnect_maxsleeptime 16 # max sleep value to cap at nss_reconnect_maxconntries 2 # how many tries before sleeping # This leads to a delay of 15 seconds (1+2+4+8=15) After replacing chown 0:0 with chown root:root, bootmisc doesn't lock anymore. Definitely you were right. Good night Jj robbat2@gentoo.org 2006-08-04 07:47:54 0000 *** Bug 142790 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2006-08-04 08:52:56 0000 sorry, but this is by design and is required by spec: http://www.opengroup.org/onlinepubs/009695399/utilities/chown.html OPERANDS The following operands shall be supported: owner[:group] A user ID and optional group ID to be assigned to file. The owner portion of this operand shall be a user name from the user database or a numeric user ID. Either specifies a user ID which shall be given to each file named by one of the file operands. If a numeric owner operand exists in the user database as a user name, the user ID number associated with that user name shall be used as the user ID. Similarly, if the group portion of this operand is present, it shall be a group name from the group database or a numeric group ID. Either specifies a group ID which shall be given to each file. If a numeric group operand exists in the group database as a group name, the group ID number associated with that group name shall be used as the group ID. what this means is that if you have "0" as a username, then the uid associated with that username will utilized rather than the numeric uid 0 so add this to the end of your /etc/passwd: 0:x:3456:3456::/:/bin/false then run: touch foo chown 0 foo stat -c%u foo notice how the output is uid 3456, not uid 0 robbat2@gentoo.org 2006-08-05 10:48:21 0000 Spanky: a LOT of other stuff in the system forbids numeric values as usernames. # useradd -u 3456 -g 100 -s /bin/false 0 useradd: invalid user name '0' (add it manually now instead) # echo "0:x:3456:100:testcase:/tmp:/bin/false" >>/etc/passwd (now show how getent is broken) # getent passwd 0 root:x:0:0:root:/root:/bin/bash The one alternative to not fixing this is to write a service that rotates the correct nsswitch into place at the correct time, which isn't an easy task. (uberlord tried a few variation ideas on it i know). A different alternative would be to find a chown-like tool that can explicitly be told that it's input is a numeric uid/gid and should not be looked up otherwise. vapier@gentoo.org 2006-08-05 13:38:41 0000 > a LOT of other stuff in the system forbids numeric values as usernames. what's your point ? chown has a spec that is accepted by everyone, it is certainly not our place to go changing that behavior is said behavior stupid ? certainly is imho, but it's in the spec, thus it will always retain that behavior until the POSIX/IEEE/whoever changes their mind > A different alternative would be to find a chown-like tool that can explicitly > be told that it's input is a numeric uid/gid and should not be looked up > otherwise. what i was thinking of was asking the coreutils guys what they thought of a flag to chown/chgrp that explicitly forces numeric ids to not be looked up ... like a -n flag or something robbat2@gentoo.org 2006-08-05 14:52:56 0000 +1 on the -n numeric flag. I'll even code it if they like the idea. vapier@gentoo.org 2006-08-05 15:23:45 0000 or change bootmisc to 'use net' robbat2@gentoo.org 2006-08-05 15:30:26 0000 'use net' does solve it for those with a local LDAP server, and is also a conflict with runlevels, since bootmisc is in boot, and net is in default. vapier@gentoo.org 2006-08-05 17:36:23 0000 fixed in svn by dropping the chown as it is just a sanity check this will cause problems for people who run the `mkdir` as a non root user, but then again in that case the `chown` would have failed anyways as non-root users cannot chown to 0:0 cardoe@gentoo.org 2006-08-08 09:04:02 0000 Created an attachment (id=93767) coreutils-numeric.patch Adds -n and --numeric to chown and chgrp. I tried to change as little code as possible. I'm sure you won't like it Spanky. 93767 2006-08-08 09:04 0000 coreutils-numeric.patch coreutils-numeric.patch text/plain ZGlmZiAtTnVyIGNvcmV1dGlscy01Ljk3L2xpYi91c2Vyc3BlYy5jIGNvcmV1dGlscy01Ljk3LW51 bWVyaWMvbGliL3VzZXJzcGVjLmMKLS0tIGNvcmV1dGlscy01Ljk3L2xpYi91c2Vyc3BlYy5jCTIw MDUtMDktMjIgMDI6MDU6MzkuMDAwMDAwMDAwIC0wNDAwCisrKyBjb3JldXRpbHMtNS45Ny1udW1l cmljL2xpYi91c2Vyc3BlYy5jCTIwMDYtMDgtMDggMTE6MjI6MzQuMDAwMDAwMDAwIC0wNDAwCkBA IC0xMDUsNyArMTA1LDcgQEAKIHN0YXRpYyBjaGFyIGNvbnN0ICoKIHBhcnNlX3dpdGhfc2VwYXJh dG9yIChjaGFyIGNvbnN0ICpzcGVjLCBjaGFyIGNvbnN0ICpzZXBhcmF0b3IsCiAJCSAgICAgIHVp ZF90ICp1aWQsIGdpZF90ICpnaWQsCi0JCSAgICAgIGNoYXIgKip1c2VybmFtZSwgY2hhciAqKmdy b3VwbmFtZSkKKwkJICAgICAgY2hhciAqKnVzZXJuYW1lLCBjaGFyICoqZ3JvdXBuYW1lLCBib29s IG51bWVyaWMpCiB7CiAgIHN0YXRpYyBjb25zdCBjaGFyICpFX2ludmFsaWRfdXNlciA9IE5fKCJp bnZhbGlkIHVzZXIiKTsKICAgc3RhdGljIGNvbnN0IGNoYXIgKkVfaW52YWxpZF9ncm91cCA9IE5f KCJpbnZhbGlkIGdyb3VwIik7CkBAIC0xNTksNyArMTU5LDExIEBACiAKICAgaWYgKHUgIT0gTlVM TCkKICAgICB7Ci0gICAgICBwd2QgPSBnZXRwd25hbSAodSk7CisgICAgICBpZihudW1lcmljKQor CXB3ZCA9IE5VTEw7CisgICAgICBlbHNlCisgICAgICAJcHdkID0gZ2V0cHduYW0gKHUpOworCiAg ICAgICBpZiAocHdkID09IE5VTEwpCiAJewogCSAgYm9vbCB1c2VfbG9naW5fZ3JvdXAgPSAoc2Vw YXJhdG9yICE9IE5VTEwgJiYgZyA9PSBOVUxMKTsKQEAgLTE5NSw3ICsxOTksMTEgQEAKICAgaWYg KGcgIT0gTlVMTCAmJiBlcnJvcl9tc2cgPT0gTlVMTCkKICAgICB7CiAgICAgICAvKiBFeHBsaWNp dCBncm91cC4gICovCi0gICAgICBncnAgPSBnZXRncm5hbSAoZyk7CisgICAgICBpZihudW1lcmlj KQorCWdycCA9IE5VTEw7CisgICAgICBlbHNlCisgICAgICAgIGdycCA9IGdldGdybmFtIChnKTsK KwogICAgICAgaWYgKGdycCA9PSBOVUxMKQogCXsKIAkgIHVuc2lnbmVkIGxvbmcgaW50IHRtcDsK QEAgLTI0MywxMSArMjUxLDExIEBACiAKIGNoYXIgY29uc3QgKgogcGFyc2VfdXNlcl9zcGVjIChj aGFyIGNvbnN0ICpzcGVjLCB1aWRfdCAqdWlkLCBnaWRfdCAqZ2lkLAotCQkgY2hhciAqKnVzZXJu YW1lLCBjaGFyICoqZ3JvdXBuYW1lKQorCQkgY2hhciAqKnVzZXJuYW1lLCBjaGFyICoqZ3JvdXBu YW1lLCBib29sIG51bWVyaWMpCiB7CiAgIGNoYXIgY29uc3QgKmNvbG9uID0gc3RyY2hyIChzcGVj LCAnOicpOwogICBjaGFyIGNvbnN0ICplcnJvcl9tc2cgPQotICAgIHBhcnNlX3dpdGhfc2VwYXJh dG9yIChzcGVjLCBjb2xvbiwgdWlkLCBnaWQsIHVzZXJuYW1lLCBncm91cG5hbWUpOworICAgIHBh cnNlX3dpdGhfc2VwYXJhdG9yIChzcGVjLCBjb2xvbiwgdWlkLCBnaWQsIHVzZXJuYW1lLCBncm91 cG5hbWUsIG51bWVyaWMpOwogCiAgIGlmICghY29sb24gJiYgZXJyb3JfbXNnKQogICAgIHsKQEAg LTI1OSw3ICsyNjcsNyBAQAogCiAgICAgICBjaGFyIGNvbnN0ICpkb3QgPSBzdHJjaHIgKHNwZWMs ICcuJyk7CiAgICAgICBpZiAoZG90Ci0JICAmJiAhIHBhcnNlX3dpdGhfc2VwYXJhdG9yIChzcGVj LCBkb3QsIHVpZCwgZ2lkLCB1c2VybmFtZSwgZ3JvdXBuYW1lKSkKKwkgICYmICEgcGFyc2Vfd2l0 aF9zZXBhcmF0b3IgKHNwZWMsIGRvdCwgdWlkLCBnaWQsIHVzZXJuYW1lLCBncm91cG5hbWUsIG51 bWVyaWMpKQogCWVycm9yX21zZyA9IE5VTEw7CiAgICAgfQogCkBAIC0yODQsNyArMjkyLDcgQEAK ICAgICAgIGNoYXIgKnRtcDsKIAogICAgICAgdG1wID0gc3RyZHVwIChhcmd2W2ldKTsKLSAgICAg IGUgPSBwYXJzZV91c2VyX3NwZWMgKHRtcCwgJnVpZCwgJmdpZCwgJnVzZXJuYW1lLCAmZ3JvdXBu YW1lKTsKKyAgICAgIGUgPSBwYXJzZV91c2VyX3NwZWMgKHRtcCwgJnVpZCwgJmdpZCwgJnVzZXJu YW1lLCAmZ3JvdXBuYW1lLCBmYWxzZSk7CiAgICAgICBmcmVlICh0bXApOwogICAgICAgcHJpbnRm ICgiJXM6ICVsdSAlbHUgJXMgJXMgJXNcbiIsCiAJICAgICAgYXJndltpXSwKZGlmZiAtTnVyIGNv cmV1dGlscy01Ljk3L2xpYi91c2Vyc3BlYy5oIGNvcmV1dGlscy01Ljk3LW51bWVyaWMvbGliL3Vz ZXJzcGVjLmgKLS0tIGNvcmV1dGlscy01Ljk3L2xpYi91c2Vyc3BlYy5oCTIwMDQtMDQtMDQgMDE6 NTE6MTEuMDAwMDAwMDAwIC0wNTAwCisrKyBjb3JldXRpbHMtNS45Ny1udW1lcmljL2xpYi91c2Vy c3BlYy5oCTIwMDYtMDgtMDggMTE6NDM6NDEuMDAwMDAwMDAwIC0wNDAwCkBAIC0yLDkgKzIsMTAg QEAKICMgZGVmaW5lIFVTRVJTUEVDX0ggMQogCiAjIGluY2x1ZGUgPHN5cy90eXBlcy5oPgorI2lu Y2x1ZGUgPHN0ZGJvb2wuaD4KIAogY29uc3QgY2hhciAqCiBwYXJzZV91c2VyX3NwZWMgKGNvbnN0 IGNoYXIgKnNwZWNfYXJnLCB1aWRfdCAqdWlkLCBnaWRfdCAqZ2lkLAotCQkgY2hhciAqKnVzZXJu YW1lX2FyZywgY2hhciAqKmdyb3VwbmFtZV9hcmcpOworCQkgY2hhciAqKnVzZXJuYW1lX2FyZywg Y2hhciAqKmdyb3VwbmFtZV9hcmcsIGJvb2wgbnVtZXJpYyk7CiAKICNlbmRpZgpkaWZmIC1OdXIg Y29yZXV0aWxzLTUuOTcvc3JjL2NoZ3JwLmMgY29yZXV0aWxzLTUuOTctbnVtZXJpYy9zcmMvY2hn cnAuYwotLS0gY29yZXV0aWxzLTUuOTcvc3JjL2NoZ3JwLmMJMjAwNi0wNS0yNyAxMDo1OTowOS4w MDAwMDAwMDAgLTA0MDAKKysrIGNvcmV1dGlscy01Ljk3LW51bWVyaWMvc3JjL2NoZ3JwLmMJMjAw Ni0wOC0wOCAxMTo1Nzo0NC4wMDAwMDAwMDAgLTA0MDAKQEAgLTcxLDYgKzcxLDcgQEAKICAgeyJz aWxlbnQiLCBub19hcmd1bWVudCwgTlVMTCwgJ2YnfSwKICAgeyJyZWZlcmVuY2UiLCByZXF1aXJl ZF9hcmd1bWVudCwgTlVMTCwgUkVGRVJFTkNFX0ZJTEVfT1BUSU9OfSwKICAgeyJ2ZXJib3NlIiwg bm9fYXJndW1lbnQsIE5VTEwsICd2J30sCisgIHsibnVtZXJpYyIsIG5vX2FyZ3VtZW50LCBOVUxM LCAnbid9LAogICB7R0VUT1BUX0hFTFBfT1BUSU9OX0RFQ0x9LAogICB7R0VUT1BUX1ZFUlNJT05f T1BUSU9OX0RFQ0x9LAogICB7TlVMTCwgMCwgTlVMTCwgMH0KQEAgLTc5LDEzICs4MCwxNSBAQAog LyogUmV0dXJuIHRoZSBncm91cCBJRCBvZiBOQU1FLCBvciAtMSBpZiBubyBuYW1lIHdhcyBzcGVj aWZpZWQuICAqLwogCiBzdGF0aWMgZ2lkX3QKLXBhcnNlX2dyb3VwIChjb25zdCBjaGFyICpuYW1l KQorcGFyc2VfZ3JvdXAgKGNvbnN0IGNoYXIgKm5hbWUsIGJvb2wgbnVtZXJpYykKIHsKICAgZ2lk X3QgZ2lkID0gLTE7CisgIHN0cnVjdCBncm91cCAqZ3JwID0gTlVMTDsKIAogICBpZiAoKm5hbWUp CiAgICAgewotICAgICAgc3RydWN0IGdyb3VwICpncnAgPSBnZXRncm5hbSAobmFtZSk7CisgICAg ICBpZighbnVtZXJpYykKKyAgICAgICAgZ3JwID0gZ2V0Z3JuYW0gKG5hbWUpOwogICAgICAgaWYg KGdycCkKIAlnaWQgPSBncnAtPmdyX2dpZDsKICAgICAgIGVsc2UKQEAgLTEyOSw2ICsxMzIsMTAg QEAKICAgICAgICAgICAgICAgICAgICAgICAgICBvd25lcnNoaXAgb2YgYSBzeW1saW5rKVxuXAog IiksIHN0ZG91dCk7CiAgICAgICBmcHV0cyAoXygiXAorICAtbiwgLS1udW1lcmljICAgICAgICAg IHRyZWF0cyBPV05FUiBhbmQgR1JPVVAgYXMgbnVtZXJpYyBieSBkZWZhdWx0LiBVc2VyICcwJ1xu XAorICAgICAgICAgICAgICAgICAgICAgICAgIHdvdWxkIGJlIHJvb3QgcmF0aGVyIHRoZW4gdXNl cm5hbWUgJzAnLlxuXAorIiksIHN0ZG91dCk7CisgICAgICBmcHV0cyAoXygiXAogICAgICAgLS1u by1wcmVzZXJ2ZS1yb290IGRvIG5vdCB0cmVhdCBgLycgc3BlY2lhbGx5ICh0aGUgZGVmYXVsdClc blwKICAgICAgIC0tcHJlc2VydmUtcm9vdCAgICBmYWlsIHRvIG9wZXJhdGUgcmVjdXJzaXZlbHkg b24gYC8nXG5cCiAiKSwgc3Rkb3V0KTsKQEAgLTE5Myw3ICsyMDAsNyBAQAogCiAgIGNob3B0X2lu aXQgKCZjaG9wdCk7CiAKLSAgd2hpbGUgKChvcHRjID0gZ2V0b3B0X2xvbmcgKGFyZ2MsIGFyZ3Ys ICJITFBSY2ZodiIsIGxvbmdfb3B0aW9ucywgTlVMTCkpCisgIHdoaWxlICgob3B0YyA9IGdldG9w dF9sb25nIChhcmdjLCBhcmd2LCAiSExQUmNmaHZuIiwgbG9uZ19vcHRpb25zLCBOVUxMKSkKIAkg IT0gLTEpCiAgICAgewogICAgICAgc3dpdGNoIChvcHRjKQpAQCAtMjQ2LDYgKzI1MywxMCBAQAog CWNhc2UgJ3YnOgogCSAgY2hvcHQudmVyYm9zaXR5ID0gVl9oaWdoOwogCSAgYnJlYWs7CisJCisJ Y2FzZSAnbic6CisJICBjaG9wdC5udW1lcmljID0gdHJ1ZTsKKwkgIGJyZWFrOwogCiAJY2FzZV9H RVRPUFRfSEVMUF9DSEFSOwogCWNhc2VfR0VUT1BUX1ZFUlNJT05fQ0hBUiAoUFJPR1JBTV9OQU1F LCBBVVRIT1JTKTsKQEAgLTI5OSw3ICszMTAsNyBAQAogICAgIHsKICAgICAgIGNoYXIgKmdyb3Vw X25hbWUgPSBhcmd2W29wdGluZCsrXTsKICAgICAgIGNob3B0Lmdyb3VwX25hbWUgPSAoKmdyb3Vw X25hbWUgPyBncm91cF9uYW1lIDogTlVMTCk7Ci0gICAgICBnaWQgPSBwYXJzZV9ncm91cCAoZ3Jv dXBfbmFtZSk7CisgICAgICBnaWQgPSBwYXJzZV9ncm91cCAoZ3JvdXBfbmFtZSwgY2hvcHQubnVt ZXJpYyk7CiAgICAgfQogCiAgIGlmIChjaG9wdC5yZWN1cnNlICYgcHJlc2VydmVfcm9vdCkKZGlm ZiAtTnVyIGNvcmV1dGlscy01Ljk3L3NyYy9jaG93bi1jb3JlLmMgY29yZXV0aWxzLTUuOTctbnVt ZXJpYy9zcmMvY2hvd24tY29yZS5jCi0tLSBjb3JldXRpbHMtNS45Ny9zcmMvY2hvd24tY29yZS5j CTIwMDUtMDUtMzAgMDM6MzE6NTEuMDAwMDAwMDAwIC0wNDAwCisrKyBjb3JldXRpbHMtNS45Ny1u dW1lcmljL3NyYy9jaG93bi1jb3JlLmMJMjAwNi0wOC0wOCAxMTowNzo1MC4wMDAwMDAwMDAgLTA0 MDAKQEAgLTU3LDYgKzU3LDcgQEAKICAgY2hvcHQtPmZvcmNlX3NpbGVudCA9IGZhbHNlOwogICBj aG9wdC0+dXNlcl9uYW1lID0gTlVMTDsKICAgY2hvcHQtPmdyb3VwX25hbWUgPSBOVUxMOworICBj aG9wdC0+bnVtZXJpYyA9IGZhbHNlOwogfQogCiBleHRlcm4gdm9pZApkaWZmIC1OdXIgY29yZXV0 aWxzLTUuOTcvc3JjL2Nob3duLWNvcmUuaCBjb3JldXRpbHMtNS45Ny1udW1lcmljL3NyYy9jaG93 bi1jb3JlLmgKLS0tIGNvcmV1dGlscy01Ljk3L3NyYy9jaG93bi1jb3JlLmgJMjAwNS0wNS0xNCAw Mzo1ODozNi4wMDAwMDAwMDAgLTA0MDAKKysrIGNvcmV1dGlscy01Ljk3LW51bWVyaWMvc3JjL2No b3duLWNvcmUuaAkyMDA2LTA4LTA4IDExOjA2OjE0LjAwMDAwMDAwMCAtMDQwMApAQCAtNjQsNiAr NjQsMTAgQEAKIAogICAvKiBUaGUgbmFtZSBvZiB0aGUgZ3JvdXAgdG8gd2hpY2ggb3duZXJzaGlw IG9mIHRoZSBmaWxlcyBpcyBiZWluZyBnaXZlbi4gKi8KICAgY2hhciAqZ3JvdXBfbmFtZTsKKwor ICAvKiBXaGV0aGVyIHRoZSBzdXBwbGllZCBPV05FUi9HUk9VUCBjb21ibyBzaG91bGQgYmUgdHJl YXRlZCBhcyBudW1lcmljIG9yCisgICAgIGRlZmF1bHRseSBhcyBuYW1lIHRoZW4gbnVtZXJpYy4g Ki8KKyAgYm9vbCBudW1lcmljOwogfTsKIAogdm9pZApkaWZmIC1OdXIgY29yZXV0aWxzLTUuOTcv c3JjL2Nob3duLmMgY29yZXV0aWxzLTUuOTctbnVtZXJpYy9zcmMvY2hvd24uYwotLS0gY29yZXV0 aWxzLTUuOTcvc3JjL2Nob3duLmMJMjAwNS0wNS0xNCAwMzo1ODozNi4wMDAwMDAwMDAgLTA0MDAK KysrIGNvcmV1dGlscy01Ljk3LW51bWVyaWMvc3JjL2Nob3duLmMJMjAwNi0wOC0wOCAxMTo1Nzoz My4wMDAwMDAwMDAgLTA0MDAKQEAgLTc4LDYgKzc4LDcgQEAKICAgeyJzaWxlbnQiLCBub19hcmd1 bWVudCwgTlVMTCwgJ2YnfSwKICAgeyJyZWZlcmVuY2UiLCByZXF1aXJlZF9hcmd1bWVudCwgTlVM TCwgUkVGRVJFTkNFX0ZJTEVfT1BUSU9OfSwKICAgeyJ2ZXJib3NlIiwgbm9fYXJndW1lbnQsIE5V TEwsICd2J30sCisgIHsibnVtZXJpYyIsIG5vX2FyZ3VtZW50LCBOVUxMLCAnbid9LAogICB7R0VU T1BUX0hFTFBfT1BUSU9OX0RFQ0x9LAogICB7R0VUT1BUX1ZFUlNJT05fT1BUSU9OX0RFQ0x9LAog ICB7TlVMTCwgMCwgTlVMTCwgMH0KQEAgLTExMCw2ICsxMTEsMTAgQEAKICAgICAgICAgICAgICAg ICAgICAgICAgICBvd25lcnNoaXAgb2YgYSBzeW1saW5rKVxuXAogIiksIHN0ZG91dCk7CiAgICAg ICBmcHV0cyAoXygiXAorICAtbiwgLS1udW1lcmljICAgICAgICAgIHRyZWF0cyBPV05FUiBhbmQg R1JPVVAgYXMgbnVtZXJpYyBieSBkZWZhdWx0LiBVc2VyICcwJ1xuXAorICAgICAgICAgICAgICAg ICAgICAgICAgIHdvdWxkIGJlIHJvb3QgcmF0aGVyIHRoZW4gdXNlcm5hbWUgJzAnLlxuXAorIiks IHN0ZG91dCk7CisgICAgICBmcHV0cyAoXygiXAogICAgICAgLS1mcm9tPUNVUlJFTlRfT1dORVI6 Q1VSUkVOVF9HUk9VUFxuXAogICAgICAgICAgICAgICAgICAgICAgICAgIGNoYW5nZSB0aGUgb3du ZXIgYW5kL29yIGdyb3VwIG9mIGVhY2ggZmlsZSBvbmx5IGlmXG5cCiAgICAgICAgICAgICAgICAg ICAgICAgICAgaXRzIGN1cnJlbnQgb3duZXIgYW5kL29yIGdyb3VwIG1hdGNoIHRob3NlIHNwZWNp ZmllZFxuXApAQCAtMTk1LDcgKzIwMCw3IEBACiAKICAgY2hvcHRfaW5pdCAoJmNob3B0KTsKIAot ICB3aGlsZSAoKG9wdGMgPSBnZXRvcHRfbG9uZyAoYXJnYywgYXJndiwgIkhMUFJjZmh2IiwgbG9u Z19vcHRpb25zLCBOVUxMKSkKKyAgd2hpbGUgKChvcHRjID0gZ2V0b3B0X2xvbmcgKGFyZ2MsIGFy Z3YsICJITFBSY2Zodm4iLCBsb25nX29wdGlvbnMsIE5VTEwpKQogCSAhPSAtMSkKICAgICB7CiAg ICAgICBzd2l0Y2ggKG9wdGMpCkBAIC0yMzgsNyArMjQzLDcgQEAKIAkgICAgY2hhciAqdV9kdW1t eSwgKmdfZHVtbXk7CiAJICAgIGNvbnN0IGNoYXIgKmUgPSBwYXJzZV91c2VyX3NwZWMgKG9wdGFy ZywKIAkJCQkJICAgICAmcmVxdWlyZWRfdWlkLCAmcmVxdWlyZWRfZ2lkLAotCQkJCQkgICAgICZ1 X2R1bW15LCAmZ19kdW1teSk7CisJCQkJCSAgICAgJnVfZHVtbXksICZnX2R1bW15LCBjaG9wdC5u dW1lcmljKTsKIAkgICAgaWYgKGUpCiAJICAgICAgZXJyb3IgKEVYSVRfRkFJTFVSRSwgMCwgIiVz OiAlcyIsIHF1b3RlIChvcHRhcmcpLCBlKTsKIAkgICAgYnJlYWs7CkBAIC0yNjAsNiArMjY1LDEw IEBACiAJICBjaG9wdC52ZXJib3NpdHkgPSBWX2hpZ2g7CiAJICBicmVhazsKIAorCWNhc2UgJ24n OgorCSAgY2hvcHQubnVtZXJpYyA9IHRydWU7CisJICBicmVhazsKKwogCWNhc2VfR0VUT1BUX0hF TFBfQ0hBUjsKIAljYXNlX0dFVE9QVF9WRVJTSU9OX0NIQVIgKFBST0dSQU1fTkFNRSwgQVVUSE9S Uyk7CiAJZGVmYXVsdDoKQEAgLTMxMyw3ICszMjIsNyBAQAogICBlbHNlCiAgICAgewogICAgICAg Y29uc3QgY2hhciAqZSA9IHBhcnNlX3VzZXJfc3BlYyAoYXJndltvcHRpbmRdLCAmdWlkLCAmZ2lk LAotCQkJCSAgICAgICAmY2hvcHQudXNlcl9uYW1lLCAmY2hvcHQuZ3JvdXBfbmFtZSk7CisJCQkJ ICAgICAgICZjaG9wdC51c2VyX25hbWUsICZjaG9wdC5ncm91cF9uYW1lLCBjaG9wdC5udW1lcmlj KTsKICAgICAgIGlmIChlKQogICAgICAgICBlcnJvciAoRVhJVF9GQUlMVVJFLCAwLCAiJXM6ICVz IiwgcXVvdGUgKGFyZ3Zbb3B0aW5kXSksIGUpOwogCg==