Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001341 [1003.1(2016)/Issue7+TC2] System Interfaces Objection Error 2020-05-05 04:53 2020-05-07 14:02
Reporter kre View Status public  
Assigned To
Priority normal Resolution Withdrawn  
Status Closed  
Name Robert Elz
User Reference
Section posix_spawn
Page Number 1452 ff.
Line Number 48227 ff.
Interp Status ---
Final Accepted Text
Summary 0001341: The resolution of 0001208 as amended by Note: 0004830 is incorrect
Description Issue 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 Note: 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 Note: 0004851 to 0001340
notwithstanding - I wasn't thinking when I wrote those either).

The text proposed before Note: 0004830 was added appears better.
Desired Action Delete Note: 0004830 and return to the previous resolution of 0001208
Tags No tags attached.
Attached Files

- Relationships

-  Notes
geoffclare (manager)
2020-05-05 08:18

The text being amended by Note: 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 (reporter)
2020-05-05 15:28
edited on: 2020-05-05 17:36

You're right, I missed the 'p' in the function name in Note: 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 Note: 0004830 is wrong - but now what I suggest is to instead

    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 (Note: 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 (manager)
2020-05-06 08:47

Re Note: 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 (manager)
2020-05-07 08:18
edited on: 2020-05-07 08:19

Re Note: 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 (reporter)
2020-05-07 10:56

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 05:07 kre Note Added: 0004852
2020-05-05 05:09 kre Note Deleted: 0004852
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

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker