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
