Re: [1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
Just floating this out there... While a posix_spawnp() kernel imp doing PATH searches relative to the parent's pwd is a well defined behavior, should there be an additional file_action that search for the executable happens after the chdir action; for the case where PATH, as inherited by the child environment, has "./" or "../" as initial element of a PATH entry? -Original Message- From: Austin Group Bug Tracker To: austin-group-l Sent: Thu, May 7, 2020 04:21 AM Subject: [1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1341 == Reported By:kre Assigned To: == Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1341 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization:User Reference: Section: posix_spawn Page Number:1452 ff. Line Number: 48227 ff. Interp Status: --- Final Accepted Text: == Date Submitted: 2020-05-05 04:53 UTC Last Modified: 2020-05-07 08:18 UTC == Summary: The resolution of https://austingroupbugs.net/view.php?id=1208 as amended by https://austingroupbugs.net/view.php?id=1208#c4830 is incorrect == -- (0004867) geoffclare (manager) - 2020-05-07 08:18 https://austingroupbugs.net/view.php?id=1341#c4867 -- Re https://austingroupbugs.net/view.php?id=1341#c4858 "could someone tell me if there is actually an implementation of posix_spawnp() that actually processes the chdir option [...] in the way it is intended here?"Casper Dik reported on the mailing list:The Solaris posix_spawnp() system call implementation does has an action to change chdir and it will actually search the PATH in the kernel.While the kernel has the ability the execute the file actions after the exec as we are still in control, the native syscall posix_spawn implementation uses the exact order as a libc implementation is forced to obey.The PATH being searched is not necessarily the same PATH in the child process but that of the parent. Issue History Date Modified Username FieldChange == 2020-05-05 04:53 kreNew Issue 2020-05-05 04:53 kreName => Robert Elz 2020-05-05 04:53 kreSection => posix_spawn 2020-05-05 04:53 krePage Number => 1452 ff. 2020-05-05 04:53 kreLine Number => 48227 ff. 2020-05-05 05:07 kreNote Added: 0004852 2020-05-05 05:09 kreNote Deleted: 0004852 2020-05-05 08:18 geoffclare Note Added: 0004853 2020-05-05 15:28 kreNote Added: 0004858 2020-05-05 15:30 kreNote Edited: 0004858 2020-05-05 17:36 kreNote Edited: 0004858 2020-05-06 08:47 geoffclare Note Added: 0004865 2020-05-07 08:18 geoffclare Note Added: 0004867 ==
Re: [1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
Date:Sat, 09 May 2020 16:42:56 +0200 From:casper@oracle.com Message-ID: <202005091442.049egure018...@room101.nl.oracle.com> | Why? Our implementation search in the kernel; it is perhaps 20 lines of | code? It is a matter of what belongs where. One can put almost everything in the kernel, if desired - old pre-unix OS's tended to have the entire command interpreter (aka shell) in the kernel. Keeping the kernel interfaces simple, and clean, is important (IMO). | Yeah, that should work though not really recommended :-) Not recommended at all! kre
Re: [1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
Date:Sat, 9 May 2020 14:41:33 + (UTC) From:shwaresyst Message-ID: <1788240209.656488.1589035293...@mail.yahoo.com> | His 'not necessarily' refers to PATH resolutions, with respect | to relative paths, It clearly doesn't. But Casper is obviously reading these messages so can clarify if needed. But The PATH being searched refers to the PATH variable from the environment. The point is that when one passes an environment to the child, it may contain a setting for PATH which is different from the one present in the parent. But it is the PATH in the parent that is used for locating the command (if it contains no '/' in its name, if it does, posix_spawnp() is simply posix_spawn()). When PATH contains relative path entries (which is not a good thing to do, but is permitted): | resolved against the parent's pwd or the child's post-chdir file | action pwd. It is always the latter (as specified). All you need do is look at the new text in note 4830 (bug 1208) (the clarification that started this discussion when I missed seeing the 3rd 'p' in posix_spawnp()) determine that. | Before the action, or no action is added like with posix_spawn(), | those are the same; after they are usually different. Actually, I doubt that the chdir() file actions are likely to be used very much, so they'd usually be the same - but I know what you mean. You don't need to explain the use cases, you just need to correctly interpret what is going on here. kre
Re: [1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
>That's what makes them evil to implement in kernel implementation >of posix_spawn where the path search for posix_spawnp is to be in >user code (where it belongs). Why? Our implementation search in the kernel; it is perhaps 20 lines of code? > | for the case where PATH, as inherited by the child environment, > >The PATH in the child environment seems to be irrelevant (other >than that is what the child, once it is running, sees). > > | has "./" or "../" as initial element of a PATH entry? > >You mean any relative path (anything that does not start with a '/'). >There doesn't have to be a '.' to get a PWD relative path (though that >is certainly one way). Yeah, that should work though not really recommended :-) Casper
Re: [1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
No, I did not misunderstand. His 'not necessarily' refers to PATH resolutions, with respect to relative paths, resolved against the parent's pwd or the child's post-chdir file action pwd. Before the action, or no action is added like with posix_spawn(), those are the same; after they are usually different. Various out-of-tree build scenarios may need searches for just built utilities relative to an output tree to be invoked, not a build script in the source tree that is the directory the parent is using, as a usage example where this would be relevant. On Saturday, May 9, 2020 Robert Elz wrote: Date: Sat, 9 May 2020 13:00:54 + (UTC) From: shwaresyst Message-ID: <600759678.614717.1589029254...@mail.yahoo.com> | Just floating this out there... While a posix_spawnp() kernel imp doing | PATH searches relative to the parent's pwd is a well defined behavior, I think you misunderstood: casper@oracle.com said: | The PATH being searched is not necessarily the same PATH in the child | process but that of the parent. What that refers to is the value of $PATH from the parent, not the parent's PWD. If it was intended to work as you suggest there, there would be much less of an issue (the chdir fileactions would be irrelevant, and posix_spawnp with them would be the same as without them). | should there be an additional file_action that search for the | executable happens after the chdir action; Since the file actions happen before the PATH search for the exec, that is the natural (and I believe, expected) behaviour of the current chdir and fchdir file actions. That's what makes them evil to implement in kernel implementation of posix_spawn where the path search for posix_spawnp is to be in user code (where it belongs). | for the case where PATH, as inherited by the child environment, The PATH in the child environment seems to be irrelevant (other than that is what the child, once it is running, sees). | has "./" or "../" as initial element of a PATH entry? You mean any relative path (anything that does not start with a '/'). There doesn't have to be a '.' to get a PWD relative path (though that is certainly one way). kre
Re: [1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
Date:Sat, 9 May 2020 13:00:54 + (UTC) From:shwaresyst Message-ID: <600759678.614717.1589029254...@mail.yahoo.com> | Just floating this out there... While a posix_spawnp() kernel imp doing | PATH searches relative to the parent's pwd is a well defined behavior, I think you misunderstood: casper@oracle.com said: | The PATH being searched is not necessarily the same PATH in the child | process but that of the parent. What that refers to is the value of $PATH from the parent, not the parent's PWD. If it was intended to work as you suggest there, there would be much less of an issue (the chdir fileactions would be irrelevant, and posix_spawnp with them would be the same as without them). | should there be an additional file_action that search for the | executable happens after the chdir action; Since the file actions happen before the PATH search for the exec, that is the natural (and I believe, expected) behaviour of the current chdir and fchdir file actions. That's what makes them evil to implement in kernel implementation of posix_spawn where the path search for posix_spawnp is to be in user code (where it belongs). | for the case where PATH, as inherited by the child environment, The PATH in the child environment seems to be irrelevant (other than that is what the child, once it is running, sees). | has "./" or "../" as initial element of a PATH entry? You mean any relative path (anything that does not start with a '/'). There doesn't have to be a '.' to get a PWD relative path (though that is certainly one way). kre
[1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
The following issue has been CLOSED. == https://austingroupbugs.net/view.php?id=1341 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1341 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: Closed Name: Robert Elz Organization: User Reference: Section:posix_spawn Page Number:1452 ff. Line Number:48227 ff. Interp Status: --- Final Accepted Text: Resolution: Withdrawn Fixed in Version: == Date Submitted: 2020-05-05 04:53 UTC Last Modified: 2020-05-07 14:02 UTC == Summary:The resolution of https://austingroupbugs.net/view.php?id=1208 as amended by https://austingroupbugs.net/view.php?id=1208#c4830 is incorrect == Issue History Date ModifiedUsername FieldChange == 2020-05-05 04:53 kreNew Issue 2020-05-05 04:53 kreName => Robert Elz 2020-05-05 04:53 kreSection => posix_spawn 2020-05-05 04:53 krePage Number => 1452 ff. 2020-05-05 04:53 kreLine Number => 48227 ff. 2020-05-05 05:07 kreNote Added: 0004852 2020-05-05 05:09 kreNote Deleted: 0004852 2020-05-05 08:18 geoffclare Note Added: 0004853 2020-05-05 15:28 kreNote Added: 0004858 2020-05-05 15:30 kreNote Edited: 0004858 2020-05-05 17:36 kreNote Edited: 0004858 2020-05-06 08:47 geoffclare Note Added: 0004865 2020-05-07 08:18 geoffclare Note Added: 0004867 2020-05-07 08:19 geoffclare Note Edited: 0004867 2020-05-07 10:56 kreNote Added: 0004870 2020-05-07 14:02 geoffclare Interp Status => --- 2020-05-07 14:02 geoffclare Status New => Closed 2020-05-07 14:02 geoffclare Resolution Open => Withdrawn ==
[1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1341 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1341 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:posix_spawn Page Number:1452 ff. Line Number:48227 ff. Interp Status: --- Final Accepted Text: == Date Submitted: 2020-05-05 04:53 UTC Last Modified: 2020-05-07 10:56 UTC == Summary:The resolution of https://www.austingroupbugs.net/view.php?id=1208 as amended by https://www.austingroupbugs.net/view.php?id=1208#c4830 is incorrect == -- (0004870) kre (reporter) - 2020-05-07 10:56 https://www.austingroupbugs.net/view.php?id=1341#c4870 -- OK, please close this bug... Issue History Date ModifiedUsername FieldChange == 2020-05-05 04:53 kreNew Issue 2020-05-05 04:53 kreName => Robert Elz 2020-05-05 04:53 kreSection => posix_spawn 2020-05-05 04:53 krePage Number => 1452 ff. 2020-05-05 04:53 kreLine Number => 48227 ff. 2020-05-05 05:07 kreNote Added: 0004852 2020-05-05 05:09 kreNote Deleted: 0004852 2020-05-05 08:18 geoffclare Note Added: 0004853 2020-05-05 15:28 kreNote Added: 0004858 2020-05-05 15:30 kreNote Edited: 0004858 2020-05-05 17:36 kreNote Edited: 0004858 2020-05-06 08:47 geoffclare Note Added: 0004865 2020-05-07 08:18 geoffclare Note Added: 0004867 2020-05-07 08:19 geoffclare Note Edited: 0004867 2020-05-07 10:56 kreNote Added: 0004870 ==
[1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1341 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1341 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:posix_spawn Page Number:1452 ff. Line Number:48227 ff. Interp Status: --- Final Accepted Text: == Date Submitted: 2020-05-05 04:53 UTC Last Modified: 2020-05-07 08:18 UTC == Summary:The resolution of https://austingroupbugs.net/view.php?id=1208 as amended by https://austingroupbugs.net/view.php?id=1208#c4830 is incorrect == -- (0004867) geoffclare (manager) - 2020-05-07 08:18 https://austingroupbugs.net/view.php?id=1341#c4867 -- Re https://austingroupbugs.net/view.php?id=1341#c4858 "could someone tell me if there is actually an implementation of posix_spawnp() that actually processes the chdir option [...] in the way it is intended here?" Casper Dik reported on the mailing list:The Solaris posix_spawnp() system call implementation does has an action to change chdir and it will actually search the PATH in the kernel. While the kernel has the ability the execute the file actions after the exec as we are still in control, the native syscall posix_spawn implementation uses the exact order as a libc implementation is forced to obey. The PATH being searched is not necessarily the same PATH in the child process but that of the parent. Issue History Date ModifiedUsername FieldChange == 2020-05-05 04:53 kreNew Issue 2020-05-05 04:53 kreName => Robert Elz 2020-05-05 04:53 kreSection => posix_spawn 2020-05-05 04:53 krePage Number => 1452 ff. 2020-05-05 04:53 kreLine Number => 48227 ff. 2020-05-05 05:07 kreNote Added: 0004852 2020-05-05 05:09 kreNote Deleted: 0004852 2020-05-05 08:18 geoffclare Note Added: 0004853 2020-05-05 15:28 kreNote Added: 0004858 2020-05-05 15:30 kreNote Edited: 0004858 2020-05-05 17:36 kreNote Edited: 0004858 2020-05-06 08:47 geoffclare Note Added: 0004865 2020-05-07 08:18 geoffclare Note Added: 0004867 ==
Re: [1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
The Solaris posix_spawnp() system call implementation does has an action to change chdir and it will actually search the PATH in the kernel. While the kernel has the ability the execute the file actions after the exec as we are still in control, the native syscall posix_spawn implementation uses the exact order as a libc implementation is forced to obey. The PATH being searched is not necessarily the same PATH in the child process but that of the parent. Casper
Re: [1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
Date:Wed, 6 May 2020 13:20:40 +0100 From:Geoff Clare Message-ID: <20200506122040.GA24339@lt2.masqnet> | Why so averse to what is obviously the simplest and cleanest solution? Simple, perhaps (certainly for the libc code, not so much for the kernel) clean, not even close. | If you don't want to do the string processing in the kernel, then | you can have the userland function create an array of pathnames to | try loading. That's fractionally better, but not a lot. | That approach won't work because it will repeat the list of file actions, | some of which might not be idempotent. The only possibility I can see is open(O_CREAT|O_EXCL), or (O_CREATE, 0444) - I'd be willing to simply allow those ones to fail (tell people not to use those combinations with posix_spawnp() - they aren't very likely cases) if that is the sole drawback. open(O_CREAT) is the only thing that alters anything that isn't local to the new (child) process image that I can see (there's no unlink file action I don't believe - having that would cause problems), and everything done in that vanishes as soon as the posix_spawn() fails. The alternative seems to be either extreme ugliness, or not allowing the chdir file actions at all with posix_spawnp() - and I know which of those I'd prefer (especially as nothing uses it anyway...) | Also, how would you distinguish between a path related error caused | by the attempted image load from one caused by one of the file actions? You don't - you err on the side of caution, if it might be a path error, treat it that way. If it is a file action error, the effect will be that we get the same error once for each prefix in PATH (the error won't magically go away). That's a little ineffecient, but it's only for an unlikely case (an error case), so doesn't really matter. kre
Re: [1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
Robert Elz wrote, on 06 May 2020: > > | On such a system, presumably posix_spawnp() would be a C > | library function > > Yes, so it is. > > | that calls a posix_spawnp system call passing it the value > | of PATH as an extra argument. > > but no, no thanks, we will not be putting PATH searches into the kernel. Why so averse to what is obviously the simplest and cleanest solution? The best place to try the different path prefixes is at the place where you actually use the filename, i.e. when you load the new process image from a file. If you don't want to do the string processing in the kernel, then you can have the userland function create an array of pathnames to try loading. (Then posix_spawn() could use the same system call and just pass it an array containing one pathname.) > I have an idea for an implementation method for posix_spawnp() which > might work, and allow even the fchdir "file action" (it isn't really, > chdir is a process action, it just happens to affect path resolution) > to work as well. > > But since we don't have (does anyone) the chdir file actions in the > kernel, those (for just posix_spwan) need to come first, before I can > test whether the technique I think might work is actually implementable. > > That will depend a lot on whether our posix_spawn actually does the > "return error" technique, or the "exit 127" technique on errors - if > it is the latter, then I still see no hope, but if posix_spawn() > doing a return(0) actually means that everything worked, it might be > possible (by simply doing the loop around posix_spawn() calls, modifying > the pathname according to PATH, until one works, or a non path related > error is returned). That approach won't work because it will repeat the list of file actions, some of which might not be idempotent. Also, how would you distinguish between a path related error caused by the attempted image load from one caused by one of the file actions? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
Date:Wed, 6 May 2020 08:47:56 + From:Austin Group Bug Tracker Message-ID: | The new specified behaviour is what naturally happens if posix_spawn() and | posix_spawnp() are implemented using fork and exec, as in the XRAT B.3.3 | example implementation of posix_spawn() as amended by bug 1208. (This can | be turned into a posix_spawnp() implementation by doing a PATH loop around | the execve() call, if path does not contain any slashes.) Sure, but an implementation like that is either a proof of concept, or useful only to implementations whose sole reason for implementing posix_spawn is because POSIX says it has to be available. No-one would actually use a posix_spawm implementation done that way, as its interface is far more difficult that simply doing the fork() exec() (with intervening close/sup/... calls). posix_spawn is useful in two cases... one is where fork() and exec() aren't available (and consequently its implementation cannot use them) and second (and forgotten in the rationale, though this is actually probably the far more common justification for its use) so that a BIG process can cheaply run a child process. Even vfork() has to move the memory mappings around (fork() needs to duplicate everything) and for big processes, that's a significant cost - if there's a genuine need to fork() that is tolerable, but when the fork() is followed almost immediately by an exec(), so all that work then has to be torn down (more work), it starts getting really annoying. An implementation of posix_spawn() that uses fork()/exec() is useless to overcome this problem. That is, IRL, any implementation of posix_spawn, to be useful, must be a kernel interface - a userland implementation, however possible is useless. | An implementation that chooses to make posix_spawn() a system call needs to | ensure the end result is the same as for a typical fork+exec | implementation. Yes. But just because something can be done with a "typical" (not really) fork+exec implementation (which actually means anything at all) doesn't mean it is rational (or necessarily even possible) to do it in a kernel implementation, and if the kernel implementation cannot, or will not, do it, then it is pointless having (an application that needs the functionality which is in a userland posix_spawn implementation can just use fork/exec itself - which is what posix_spawn would be doing). | On such a system, presumably posix_spawnp() would be a C | library function Yes, so it is. | that calls a posix_spawnp system call passing it the value | of PATH as an extra argument. but no, no thanks, we will not be putting PATH searches into the kernel. I have an idea for an implementation method for posix_spawnp() which might work, and allow even the fchdir "file action" (it isn't really, chdir is a process action, it just happens to affect path resolution) to work as well. But since we don't have (does anyone) the chdir file actions in the kernel, those (for just posix_spwan) need to come first, before I can test whether the technique I think might work is actually implementable. That will depend a lot on whether our posix_spawn actually does the "return error" technique, or the "exit 127" technique on errors - if it is the latter, then I still see no hope, but if posix_spawn() doing a return(0) actually means that everything worked, it might be possible (by simply doing the loop around posix_spawn() calls, modifying the pathname according to PATH, until one works, or a non path related error is returned). I don't know - I have never used it, and don't know of any NetBSD code that does (except perhaps some tests). kre
[1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1341 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1341 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:posix_spawn Page Number:1452 ff. Line Number:48227 ff. Interp Status: --- Final Accepted Text: == Date Submitted: 2020-05-05 04:53 UTC Last Modified: 2020-05-06 08:47 UTC == Summary:The resolution of https://austingroupbugs.net/view.php?id=1208 as amended by https://austingroupbugs.net/view.php?id=1208#c4830 is incorrect == -- (0004865) geoffclare (manager) - 2020-05-06 08:47 https://austingroupbugs.net/view.php?id=1341#c4865 -- Re https://austingroupbugs.net/view.php?id=1341#c4858 The new specified behaviour is what naturally happens if posix_spawn() and posix_spawnp() are implemented using fork and exec, as in the XRAT B.3.3 example implementation of posix_spawn() as amended by bug 1208. (This can be turned into a posix_spawnp() implementation by doing a PATH loop around the execve() call, if path does not contain any slashes.) An implementation that chooses to make posix_spawn() a system call needs to ensure the end result is the same as for a typical fork+exec implementation. On such a system, presumably posix_spawnp() would be a C library function that calls a posix_spawnp system call passing it the value of PATH as an extra argument. Issue History Date ModifiedUsername FieldChange == 2020-05-05 04:53 kreNew Issue 2020-05-05 04:53 kreName => Robert Elz 2020-05-05 04:53 kreSection => posix_spawn 2020-05-05 04:53 krePage Number => 1452 ff. 2020-05-05 04:53 kreLine Number => 48227 ff. 2020-05-05 05:07 kreNote Added: 0004852 2020-05-05 05:09 kreNote Deleted: 0004852 2020-05-05 08:18 geoffclare Note Added: 0004853 2020-05-05 15:28 kreNote Added: 0004858 2020-05-05 15:30 kreNote Edited: 0004858 2020-05-05 17:36 kreNote Edited: 0004858 2020-05-06 08:47 geoffclare Note Added: 0004865 ==
[1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1341 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1341 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:posix_spawn Page Number:1452 ff. Line Number:48227 ff. Interp Status: --- Final Accepted Text: == Date Submitted: 2020-05-05 04:53 UTC Last Modified: 2020-05-05 15:28 UTC == Summary:The resolution of https://www.austingroupbugs.net/view.php?id=1208 as amended by https://www.austingroupbugs.net/view.php?id=1208#c4830 is incorrect == -- (0004858) kre (reporter) - 2020-05-05 15:28 https://www.austingroupbugs.net/view.php?id=1341#c4858 -- You're right, I missed the 'p' in the function name in https://www.austingroupbugs.net/view.php?id=493#c1340 so if you want to just close this bug report (which is clearly not appropriate as it is) then please go ahead. But before you do, could someone tell me if there is actually an implementation of posix_spawnp() that actually processes the chdir option to the eventual posix_spawn in the way it is intended here? I can see that it would be possible (though rather messy and ugly) to handle the posix_spawn_file_actions_addchdir( ) type chdir call, as they just requires a whole bunch of string manipulation to the paths as they're being constructed from PATH and the arg while we build the pathname to hand to an eventual call of posix_spawn(). But handling posix_spawn_file_actions_addfchdir( ) in posix_spawnp() in general looks impossible to me - the only correct way to do it is to actually change directories (do a fchdir()) (since there is no guarantee that the directory referenced by the fd actually has a name by which it can be referenced, hence there is no guaranteed way to use any kind of string manipulation to produce paths that work from $PWD to reach sub-dirs of the directory whose fd is to be used by posix_spawn() for the internal fchdir. So, while my earlier reasoning is clearly nonsense, I still believe that the change in https://www.austingroupbugs.net/view.php?id=1208#c4830 is wrong - but now what I suggest is to instead add Use of the posix_spawn_file_actions_addfchdir() [and probably posix_spawn_file_actions_addchdir() as well] with the posix_spawnp() function produces unspecified results. after which the current intended change (https://www.austingroupbugs.net/view.php?id=1208#c4830) is clearly not required. Certainly unless there is an actual implementation of posix_spawnp() which processes each of those options in a sane way, this should be the only possible action - we cannot invent new interfaces and specify how they're required to work without at least some working (and sane - ie: working in a rational way) implementation to verify that it is indeed possible. Issue History Date ModifiedUsername FieldChange == 2020-05-05 04:53 kreNew Issue 2020-05-05 04:53 kreName => Robert Elz 2020-05-05 04:53 kreSection => posix_spawn 2020-05-05 04:53 krePage Number => 1452 ff. 2020-05-05 04:53 kreLine Number => 48227 ff. 2020-05-05 05:07 kreNote Added: 0004852 2020-05-05 05:09 kreNote Deleted: 0004852 2020-05-05 08:18 geoffclare Note Added: 0004853 2020-05-05 15:28 kreNote Added: 0004858 ==
[1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1341 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1341 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:posix_spawn Page Number:1452 ff. Line Number:48227 ff. Interp Status: --- Final Accepted Text: == Date Submitted: 2020-05-05 04:53 UTC Last Modified: 2020-05-05 08:18 UTC == Summary:The resolution of https://austingroupbugs.net/view.php?id=1208 as amended by https://austingroupbugs.net/view.php?id=1208#c4830 is incorrect == -- (0004853) geoffclare (manager) - 2020-05-05 08:18 https://austingroupbugs.net/view.php?id=1341#c4853 -- The text being amended by https://austingroupbugs.net/view.php?id=1208#c4830 is about posix_spawnp(), not posix_spawn(). The existing text states that a PATH search is done; the change is just to clarify how that search is done now that there is a "chdir" file action. Robert, please consider asking for this bug to be withdrawn. (It can then be closed straight away, instead of taking up time in a teleconference to process it as rejected.) Issue History Date ModifiedUsername FieldChange == 2020-05-05 04:53 kreNew Issue 2020-05-05 04:53 kreName => Robert Elz 2020-05-05 04:53 kreSection => posix_spawn 2020-05-05 04:53 krePage Number => 1452 ff. 2020-05-05 04:53 kreLine Number => 48227 ff. 2020-05-05 05:07 kreNote Added: 0004852 2020-05-05 05:09 kreNote Deleted: 0004852 2020-05-05 08:18 geoffclare Note Added: 0004853 ==
[1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1341 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1341 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:posix_spawn Page Number:1452 ff. Line Number:48227 ff. Interp Status: --- Final Accepted Text: == Date Submitted: 2020-05-05 04:53 UTC Last Modified: 2020-05-05 05:07 UTC == Summary:The resolution of https://www.austingroupbugs.net/view.php?id=1208 as amended by https://www.austingroupbugs.net/view.php?id=1208#c4830 is incorrect == -- (0004852) kre (reporter) - 2020-05-05 05:07 https://www.austingroupbugs.net/view.php?id=1341#c4852 -- I cannot (it seems) delete or edit the Summary, description or Desired action - but all references bu https://www.austingroupbugs.net/view.php?id=1208#c4830 should have been to https://www.austingroupbugs.net/view.php?id=1208#c4832 Sorry about that - if someone can fix it, this note could be deleted... Issue History Date ModifiedUsername FieldChange == 2020-05-05 04:53 kreNew Issue 2020-05-05 04:53 kreName => Robert Elz 2020-05-05 04:53 kreSection => posix_spawn 2020-05-05 04:53 krePage Number => 1452 ff. 2020-05-05 04:53 kreLine Number => 48227 ff. 2020-05-05 05:07 kreNote Added: 0004852 ==
[1003.1(2016)/Issue7+TC2 0001341]: The resolution of bugid:1208 as amended by bugnote:4830 is incorrect
The following issue has been SUBMITTED. == https://www.austingroupbugs.net/view.php?id=1341 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1341 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:posix_spawn Page Number:1452 ff. Line Number:48227 ff. Interp Status: --- Final Accepted Text: == Date Submitted: 2020-05-05 04:53 UTC Last Modified: 2020-05-05 04:53 UTC == Summary:The resolution of https://www.austingroupbugs.net/view.php?id=1208 as amended by https://www.austingroupbugs.net/view.php?id=1208#c4830 is incorrect Description: Issue https://www.austingroupbugs.net/view.php?id=1208 was reopened (just yesterday) but has been closed to new notes (already!) or I would have simply appended this there. The change to the resolution made bu https://www.austingroupbugs.net/view.php?id=1208#c4830 is wrong, the text was correct before. posix_spawn() is intended to be implemented as a system call (or at least be able to be implemented that way) - it cannot do PATH searches to locate utilities - the PATH search needs to have been done before calling posix_spawn() (my own comments in https://www.austingroupbugs.net/view.php?id=1340#c4851 to https://www.austingroupbugs.net/view.php?id=1340 notwithstanding - I wasn't thinking when I wrote those either). The text proposed before https://www.austingroupbugs.net/view.php?id=1208#c4830 was added appears better. Desired Action: Delete https://www.austingroupbugs.net/view.php?id=1208#c4830 and return to the previous resolution of https://www.austingroupbugs.net/view.php?id=1208 == Issue History Date ModifiedUsername FieldChange == 2020-05-05 04:53 kreNew Issue 2020-05-05 04:53 kreName => Robert Elz 2020-05-05 04:53 kreSection => posix_spawn 2020-05-05 04:53 krePage Number => 1452 ff. 2020-05-05 04:53 kreLine Number => 48227 ff. ==
