From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7487 Path: news.gmane.org!not-for-mail From: Jean-Marc Pigeon Newsgroups: gmane.linux.lib.musl.general Subject: Re: setenv if value=NULL, what say standard? Bug? Date: Thu, 23 Apr 2015 08:29:45 -0400 Message-ID: <5538E5B9.9030901@safe.ca> References: <553837F1.5080808@safe.ca> <55383E43.8010505@skarnet.org> <55384A61.5020001@safe.ca> <20150423021507.GG6817@brightrain.aerifal.cx> <5538740E.1030306@safe.ca> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020805080509050502040105" X-Trace: ger.gmane.org 1429792213 18723 80.91.229.3 (23 Apr 2015 12:30:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 12:30:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7500-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 23 14:30:07 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YlGGb-0007dn-Gr for gllmg-musl@m.gmane.org; Thu, 23 Apr 2015 14:30:05 +0200 Original-Received: (qmail 20427 invoked by uid 550); 23 Apr 2015 12:30:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20399 invoked from network); 23 Apr 2015 12:30:03 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 In-Reply-To: X-Enigmail-Version: 1.6 X-Clement-Version: 2.6-6.7 X-Clement-ID: <00717-20150423082945-a65f3b15> X-Clement-Virus-checker: ClamAV 0.98.4/20365/Wed Apr 22 18:38:41 2015 Xref: news.gmane.org gmane.linux.lib.musl.general:7487 Archived-At: This is a cryptographically signed message in MIME format. --------------ms020805080509050502040105 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/23/2015 01:08 AM, Raphael Cohn wrote: > Fail fast, fail early is always the right thing to do. I've seen > far too much code in my career that tries to 'carry on' after > encountering an unexpected condition. It's always the wrong thing > to do, even for nuclear power plants. Once you're in UB land, the > rest of your reasoning about your code is invalid. The best you can > do is gracefully shutdown and capture as much diagnostic info as is > feasible. Expecting musl to 'cover up' should be seen the same as > in the real world - cover ups just make the problem worse. this is UB, man setenv(name, NULL, override) is/was not defining if it was valid or not. Code must be resilient. Either report an error and have the documentation updated accordingly (get rid of the UB, have all old running code taking care of the new standard) or code the 'best' decision implementing code (done by glibc or uclibc so fare). >=20 > Unexpected is not the same as expected but unpleasant to deal with > eg failures to open(). And so hence the arguments about checked > and unchecked exceptions and so on. >=20 > Oh and auto restarting daemons is almost always wrong. For exactly > the same reasoning - and frequently leads to data corruption. Fully agreed with you and this was exactly my point, but reality say otherwise, in the field sometime it is seen as the only option :-{{{. >=20 > On 23 Apr 2015 05:25, "Jean-Marc Pigeon" > wrote: >=20 > On 04/22/2015 10:15 PM, Rich Felker wrote: >> On Wed, Apr 22, 2015 at 09:26:57PM -0400, Jean-Marc Pigeon >> wrote: >>>> I think the only safe conclusion is that the application is=20 >>>> incorrect and should ensure that setenv() is never called >>>> with a NULL value. >>>>=20 >>> Checked glibc, My understanding, it set something as "name=3D" >>> in the environment, so the variable is present but value is >>> "empty"i (top application to decide what to do). uclibc does >>> something similar (as far I can tell looking at source code).. >>>=20 >>>=20 >>> The application is not careful enough, but not incorrect as=20 >>> such. >=20 >> It's definitely incorrect. It's doing something that invokes=20 >> undefined behavior. >=20 >>> Note: we may have tons of applications with the same problem. >>> if we keep musl setenv like that, musl will be seen as quite=20 >>> unreliable. >=20 >> No, actually glibc is fixing this bug (maybe they already did).=20 >> See the thread beginning here: >=20 >> https://sourceware.org/ml/libc-alpha/2015-03/threads.html#00449 >=20 >> My understanding is that glibc is planning to do, or already >> does in the latest version, exactly what musl is doing. >=20 >>> If this situation is indeed UB, there is 2 options for musl: >>> 1) Swallow the problem nicely... as glibc and uclibc does. 2) >>> Report an error.. EINVAL? (and document it in manual) >>>=20 >>> Crashing at "libc" level is not an option. >=20 >> I can see how it might seem like that at first, but crashing is=20 >> actually the best possible behavior. Options 1 and 2 cover up a > I strongly disagree, crashing is not an option for a tools as=20 > musl/libc. >=20 > Think about this, you write an application working perfectly > right, but 1 in 1000000 you reach something not trapped by low > level and once in while the application (in production for month) > just stop to work because "unexpected" within musl... (so someone > will propose to set a cron to automatically restart this unreliable > daemon, hmmm...) >=20 > Far better to return "trouble" status, then it is to the > application to decide what must be done in context, as ignore, > override, bypass, crash, etc. >=20 > A sensible policy in case of UB would be for such low level code > to swallow the problem, (protect the hardware and keep the program=20 > running as much as possible). >=20 >> potentially serious bug -- it's not clear what the application >> was trying to do, most likely nobody even thought about what they >> were trying to do, and even if they did have something in mind >> it's not reliable or portable. The glibc wiki has some text taken >> from text I wrote on the topic (copied from a stack overflow >> answer I gave) here: >=20 > As reported, the crashing application is hwclock, > (util-linux-2.26), this a kind of code in the field for a very > very long time, so the library (glibc and old libc) used for linux > over the years defined an expected behavior to this "UB". As other > occurrence of this could be present too in other=20 > program/application, crashing would make a bench of applications to > be running hazard (you can have all kind situation with env > variables, near unpredictable). >=20 > Something worry me in comments I have seen in the proposed URL,=20 > IMHO purpose of musl/glibc is not to "find bugs by crashing", its=20 > purpose is to be a code "clean, lean, reliable, predictable" (as > said above, "Protect the hardware, report problem, lets the above > layer application decide what to do in case of problem"). >=20 > Crashing is not an option for code pertaining to musl/libc layer. >=20 > (:-} why bother to return an error, just crash for all problems in > open, close, write, etc. just bringing the crashing concept to the > extreme :-}). >=20 >=20 >=20 >=20 >=20 > https://sourceware.org/glibc/wiki/Style_and_Conventions#Invalid_pointer= s > >=20 >> Specifically it covers why returning an error is not a good >> idea. > My experience (for a long time now) about writing complex daemon=20 > running for months/year, it is not that straightforward (may be for > a simple application it is) >=20 >=20 >> Rich >=20 >=20 >=20 >=20 - --=20 A bient=C3=B4t =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Jean-Marc Pigeon E-Mail: jmp@safe.ca SAFE Inc. Phone: (514) 493-4280 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base <"http://www.clement.safe.ca"> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJVOOW5AAoJEAtgwJ4bBQU52jEQAJXCLoQyl0s4E9uQaAOsmA8x TEuDRsRI0wn90QaW5GdwbpUDwzPqp9d33FXkxpnQljoGX71sH17AmXfe9L7h32pG RQnlpRQy5zdxXYx1tioUvLfwfMW+PsqG5SwyzmNOKvoBMS4sC7FHrwJtYh9YZYSB hO7C6tdS8b7hJoRwzW1/4KPJRak7Z3dTD2tZiMk+4VWtzs19HQ6nwMMjAHBIw4l3 EbcLVjdjCcFVtbWC8Wr/nJQcDoAenUXrj5qfxxazPjb1AJGa91k4eGbSS7FDFiqA JT4tdpgYL4/+RkwzbjJhUJHXBisYJ29KBpq/YV3Yj/BOlSjT0z2yfu/dUlU37x/m dDP535oty1jR4l3t73yumyiXP41c8tdwK22QAaaK+4Mh+1SdkA+Eh9rsZsl7cij0 UrvLTrc4sNjD+zIvEhkdyhCZ/4SVrXpVCpxHOXO2IIB/1CDTu2a63OaNnpctrrK9 VHsGTgAZgmwGkszXUhK8cIsw4FQNog1U2CwcwJBJhk0UGkwQOG4HXtECvqD9YjhQ jIY2tFzEeG7ObwMT0AjK0KKd/aVKoCyCfNLjO3Pucww54/8aTQaWZ/mOj4fwsP01 YTrbAs2L4VDRtnHQru4THYIjKMK8P0zU991XqPhTeMGhJuP5x13cHzAoUhsw3HVh q1Ki9yFz/20JUbK/KqRt =3DVNMJ -----END PGP SIGNATURE----- --------------ms020805080509050502040105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOzCCBSOgAwIBAgIDCz+cMA0GCSqGSIb3DQEB CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTE5MDkyNjU5 WhcNMTUwOTIwMDAyMjU4WjBEMQswCQYDVQQGEwJDQTEZMBcGA1UEAxMQSmVhbi1NYXJjIFBp Z2VvbjEaMBgGCSqGSIb3DQEJARYLam1wQHNhZmUuY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCq9xU31qh4GocaLlpWBFhfbsocoZcrPC5/vYc53dzp2sc9dLGE8wJTJpGF AMVajOosoGx11kV76DmdF2gWTOjl2tNxgTlfjDtgqeuY6laDfPEoYquzcqvNAFigAhzV+oIR 1WD6RROEt7mWar8DFYvqovwGN1NWGHqnwLQ8eWa/xN/rC+rzxpFfBJKPPgaaLPSLkoAJg1Iv LrEbGgofvO+2gq46goCXvobTmCB4fG+lCqcxoAvFuGv5aJQUIyg0LrZSCsQYc7G9Z+eMNK12 pBUzMsUwgbjBu/owa0dnc452YaZHI0dq1X+27FP+vVxJdO2U6opebBk04BVvOaOtGZyPAgMB AAGjggLrMIIC5zAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFHzO2KvU9lX+uTCC7EFVdrvVptoXMB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBYGA1UdEQQPMA2BC2ptcEBzYWZlLmNhMIIBZgYDVR0g BIIBXTCCAVkwggFVBgsrBgEEAYG1NwECAzCCAUQwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwggEQBggrBgEFBQcCAjCCAQIwJxYgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB1lRoaXMgY2VydGlmaWNhdGUgd2FzIGlz c3VlZCBhY2NvcmRpbmcgdG8gdGhlIFN0YXJ0U1NMIFdlYi1vZi1UcnVzdCBDb21tdW5pdHkg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVs aWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0 aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDov L2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2Nh MEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3Mx LmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0G CSqGSIb3DQEBCwUAA4IBAQAvqGXpalMzkxyvuW6F4AJpyxCQfZElU4Xta8ChoYYOM+8mbznZ qmGhQsIgRREuRcmCCO3Ei9CZ9DvgXtOrZHAOTLoLadl/Z/A2C0QOrTPG7UiUQTQJQlubgy41 2T4b9mtIHxy+bLofsC4SnPRhSRCKAAtNPSBqPKoF9pQdAGdx2/7JGPuHLd6vH93IcZtsQcmk SjpLqGR7YSl7vSy4i/JypO5bfGTAdJPDPEHuqMYd8bM2frS9Dv6+yAb1S8C7e2032r4MUsLx 4aw5RZ5N8BqpUv9XNUr68P38B6Q/FBtZgDloUNB/Py77fLTbGq1xYhHTG8uKOlRNkWx/IZnM JFPTMYID3TCCA9kCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQID Cz+cMAkGBSsOAwIaBQCgggIdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDQyMzEyMjk0NVowIwYJKoZIhvcNAQkEMRYEFFTC3zg9kf+Bf8RQBUnBTnbZ bJMvMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgMLP5wwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNh dGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk aWF0ZSBDbGllbnQgQ0ECAws/nDANBgkqhkiG9w0BAQEFAASCAQA2w0ULfFVV7O29C4JcubvU 9Ga9Gv2uKeZ+PY5QT0dT2q67I6O8xqEJQltop+74m6Gksm4z/3KBx1xSgwK7vOqeDaDizqoC VQsDFwPPow0OxS+NzIauvJ6n61saFVyQimHOrOV/o9xfo0Jm84LAqqpcdUnOakPjEAyzHZ9V 2Y89nos2Da3zZ3bpynXBxDSr09DrxH7IshukxycSZExBEkqVjayFeyuMSYtulpDHnBaswaFo J9m2KUDm30S8eureFo4BlTc8+jaqPfp5tpciDVtxSFftNRFFBPlxYQStpfvAgWlFqyjyXdxP tbD3gU4fr0lfE4j/JpdxT9NtRFl5YBERAAAAAAAA --------------ms020805080509050502040105--