View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00013411003.1(2016/18)/Issue7+TC2System Interfacespublic2020-05-05 04:532020-05-07 14:02
Reporterkre Assigned To 
PrioritynormalSeverityObjectionTypeError
Status ClosedResolutionWithdrawn 
NameRobert Elz
Organization
User Reference
Sectionposix_spawn
Page Number1452 ff.
Line Number48227 ff.
Interp Status---
Final Accepted Text
Summary0001341: The resolution of 0001208 as amended by 0001208:0004830 is incorrect
DescriptionIssue 0001208 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 0001208:0004830 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 0001340:0004851 to 0001340
notwithstanding - I wasn't thinking when I wrote those either).

The text proposed before 0001208:0004830 was added appears better.
Desired ActionDelete 0001208:0004830 and return to the previous resolution of 0001208
TagsNo tags attached.

Activities

geoffclare

2020-05-05 08:18

manager   bugnote:0004853

The text being amended by 0001208:0004830 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.)

kre

2020-05-05 15:28

reporter   bugnote:0004858

Last edited: 2020-05-05 17:36

 You're right, I missed the 'p' in the function name in 0001208:0004830
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 that
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. And that we cannot safely do.

So, while my earlier reasoning is clearly nonsense, I still believe that
the change in 0001208:0004830 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 (0001208:0004830) 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.

geoffclare

2020-05-06 08:47

manager   bugnote:0004865

Re 0001341:0004858

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.

geoffclare

2020-05-07 08:18

manager   bugnote:0004867

Last edited: 2020-05-07 08:19

 Re 0001341:0004858 "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.

kre

2020-05-07 10:56

reporter   bugnote:0004870

OK, please close this bug...

Issue History

Date Modified Username Field Change
2020-05-05 04:53 kre New Issue
2020-05-05 04:53 kre Name => Robert Elz
2020-05-05 04:53 kre Section => posix_spawn
2020-05-05 04:53 kre Page Number => 1452 ff.
2020-05-05 04:53 kre Line Number => 48227 ff.
2020-05-05 08:18 geoffclare Note Added: 0004853
2020-05-05 15:28 kre Note Added: 0004858
2020-05-05 15:30 kre Note Edited: 0004858
2020-05-05 17:36 kre Note 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 kre Note 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