Re: posix_spawn facility
Following up on an older thread: On Tue, Apr 18, 2023 at 03:49:20PM -0500, Eric Blake wrote: > The glibc bug points to the sample posix_spawn() implementation in > POSIX XRAT - but that example implementation is non-normative and > known buggy, so it is not safe to rely on it. > > Clarifying the wording in XRAT to explicitly mention that the example > is NOT bullet-proof (and that implementations should do better) is > probably worthwhile; I'll tackle that bug report. > > > > > Second, the rational section in POSIX explains posix_spawn and > > posix_spawnp, but it does *not* actually provide an example > > implementation of posix_spawnp, only of posix_spawn. > > POSIX is silent as to whether posix_spawnp() has to fall back to 'sh' > on ENOEXEC failure. The p suffix is indeed similar to execvp() (which > DOES require a fallback to sh), but it could also just mean a > PATH-search, and not the PATH-search-and-sh-fallback of execvp(). As > we now have implementations in the wild that differ in behavior, and > use security as a reason for the divergence, it is worth getting that > clarified in POSIX. I'll file a bug against POSIX shortly, and reply > again once it is up. > > My personal preference: sh fallback on ENOEXEC is useful in execvp(), > but a bear to get right (see > https://www.austingroupbugs.net/view.php?id=1645 where POSIX has a bug > in requiring argv[0] to be the script's filename, which breaks busybox > sh and is NOT what glibc does; meanwhile, musl intentionally does NOT > do the sh fallback), so NOT doing it in posix_spawnp() would be > reasonable; but we'll have to see what the rest of the Austin Group > says. ... > > Yeah, it appears that POSIX is (accidentally) silent on whether > posix_spawnp() has to do the sh fallback on ENOEXEC; but it seems > quite reasonable that posix_spawn() being more like execle() must NOT > do a sh fallback. The Austin Group finally visited the topic today; result is that in the next version of POSIX, it will be explicit that neither posix_spawn() nor posix_spawnp() are allowed to attempt sh fallback (instead, they must fail with ENOEXEC if detected in the parent, or with status 127 if after creating the child). https://austingroupbugs.net/view.php?id=1674#c6411 Yes, it's odd that ENOEXEC normally equates to status 126, but does not do so for posix_spawn(). If you want to add an extention POSIX_SPAWN flag (for use in posix_spawnattr_setflags()) to further tweak things as an extension to the standard, that would probably be reasonable, but without implementations already implementing and relying on such extension flags, the Austin Group did not want to visit that topic today. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: posix_spawn facility
On Wed, Apr 19, 2023 at 12:10:34AM +0200, Bruno Haible wrote: > Eric Blake wrote: > > we now have implementations in the wild that differ in behavior, and > > use security as a reason for the divergence, it is worth getting that > > clarified in POSIX. I'll file a bug against POSIX shortly > > For the reference, the systems that return ENOEXEC for posix_spawnp > attempting to execute a script without #! marker are: > - glibc/Linux ≥ 2.15 > - glibc/Hurd ≥ 2.33 (commit 13adfa34aff03fd9f1c1612b537a0d736ddb6c2b) > - musl libc POSIX issue now filed as https://www.austingroupbugs.net/view.php?id=1674; although we'll have to see if my wording is acceptable or if it settles on something a bit looser (such as implementation-defined as to whether an sh fallback is attempted, rather than outright forbidden). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: posix_spawn facility
On Tue, Apr 18, 2023 at 11:25:11AM +0200, Corinna Vinschen via Cygwin wrote: > Hi Bruno, > > On Apr 17 20:44, Bruno Haible via Cygwin wrote: > > Hi Corinna, Jumping in to this conversation a bit belatedly, but as someone on the Austin Group that can try to get an answer upstream... > But I'm not *that* happy with the change yet, for two reasons. > > First, the security risk outlined in > https://sourceware.org/bugzilla/show_bug.cgi?id=13134#c0 doesn't > actually exist on Cygwin, because we don't implement setuid/setgid > executables. You can set the mode bits, but they are not acted upon. The glibc bug points to the sample posix_spawn() implementation in POSIX XRAT - but that example implementation is non-normative and known buggy, so it is not safe to rely on it. Clarifying the wording in XRAT to explicitly mention that the example is NOT bullet-proof (and that implementations should do better) is probably worthwhile; I'll tackle that bug report. > > Second, the rational section in POSIX explains posix_spawn and > posix_spawnp, but it does *not* actually provide an example > implementation of posix_spawnp, only of posix_spawn. POSIX is silent as to whether posix_spawnp() has to fall back to 'sh' on ENOEXEC failure. The p suffix is indeed similar to execvp() (which DOES require a fallback to sh), but it could also just mean a PATH-search, and not the PATH-search-and-sh-fallback of execvp(). As we now have implementations in the wild that differ in behavior, and use security as a reason for the divergence, it is worth getting that clarified in POSIX. I'll file a bug against POSIX shortly, and reply again once it is up. My personal preference: sh fallback on ENOEXEC is useful in execvp(), but a bear to get right (see https://www.austingroupbugs.net/view.php?id=1645 where POSIX has a bug in requiring argv[0] to be the script's filename, which breaks busybox sh and is NOT what glibc does; meanwhile, musl intentionally does NOT do the sh fallback), so NOT doing it in posix_spawnp() would be reasonable; but we'll have to see what the rest of the Austin Group says. > > From the above bugzilla entry I take it that on glibc, both > functions tried to run the shell if the executable isn't recognized > (up to commits d96de9634a33 / 13adfa34aff). > > However, on Cygwin, only posix_spawnp does that,but not posix_spawn. > > In fact, I read the POSIX descriptions in terms of these functions quite > thoroughly, and at no point I see it mentioned that posix_spawnp shall > *not* work like exevlp/execvp. The crucial difference between posix_spawn > and posixc_spawnp is described in an interestingly vague way: > > posix_spawnp() interprets the second parameter more elaborately than > posix_spawn(). > > If I missed the point in the POSIX docs, please tell me. Yeah, it appears that POSIX is (accidentally) silent on whether posix_spawnp() has to do the sh fallback on ENOEXEC; but it seems quite reasonable that posix_spawn() being more like execle() must NOT do a sh fallback. > > So, again, the patch is simple. But it's kind of a pity that the change > in glibc has been made without a bigger discussion. Right now, it looks > like the glibc change to posix_spawn was correct, but the change to > posix_spawnp was arbitrary. > > Has anybody attempted to ask the Austin group to define this behaviour > in posix_spawnp more concise? Is there a protocel from the Austin > group? If not, wouldn't it be time to ask the Austin group? Doing that now ;) > > > Btw, there are two more functions in the posix_spawn family meanwhile: > > * posix_spawn_file_actions_addchdir_np > > implemented by glibc [1], musl libc, macOS, FreeBSD [2], Solaris ≥ 11.3 > > used by a few packages (Firefox, Chromium, Rust) > > * posix_spawn_file_actions_addfchdir_np > > implemented in glibc, musl libc > > but not used by any package so far [3]. > > > > The next POSIX will contain these functions (without the _np suffix).[4] > > Thanks for the pointers. I'm not sure I'll have the time to implement > them soon, but I put them on my list for 3.5.0. Patches welcome! > > > Thanks, > Corinna -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Is it possible to alter Birth time?
On 10/8/20 4:33 AM, Fergus Daly via Cygwin wrote: > In Cygwin (and on some, not all, Linux file systems) the command > $ stat filename > shows all of Access, Modify, Change and Birth times of a file. > The command > $ touch [options] filename > will alter some or all of Access, Modify, Change times, as specified > in [options]. > Is it possible in Cygwin (or for that matter in Windows) to alter the > Birth time of a file or directory? Not short of deleting the file and creating a new one in its place, and even then, the birthtime is controlled by the current system clock and not something you can modify after the fact. And that answer is identical to what you have on BSD or Linux, on file systems that support birth time there. And actually, touch can't modify the change time of a file to anything other than the current time; it is only access and modify times that can be set arbitrarily. (If you REALLY want to modify birth and change times, and have superuser access, you can open the raw block device and flip bits behind the file system's back - but that's not something you want to be doing on a regular basis, nor should you attempt it while a file system is mounted on that block device) -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: calm bounces
On 4/16/20 9:35 AM, Brian Inglis wrote: On 2020-04-15 04:44, Mail Delivery System via Cygwin wrote: This is the mail system at host sourceware.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : unknown user: "corinna-cygwin" Reporting-MTA: dns; sourceware.org X-Postfix-Queue-ID: 5A264384A024 X-Postfix-Sender: rfc822; cyg...@sourceware.org Arrival-Date: Wed, 15 Apr 2020 10:44:35 + (GMT) Final-Recipient: rfc822; corinna-cyg...@cygwin.com Original-Recipient: rfc822;corinna-cyg...@cygwin.com Action: failed Status: 5.1.1 Diagnostic-Code: X-Postfix; unknown user: "corinna-cygwin" Are others also seeing these bounces from Corinna's releases: https://sourceware.org/pipermail/cygwin/2020-April/244386.html Yes. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
