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
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: pwd(1) pwd -L and multple adjacent slashes in $PWD,
>On 4/14/20 9:44 AM, casper@oracle.com wrote:
>> pwd has the -L option:
>>
>> The following options shall be supported by the implementation:
>>
>> -L
>> If the PWD environment variable contains an absolute pathname
>> of the current directory and the pathname does not contain any
>> components that are dot or dot-dot, pwd shall write this
>> pathname to standard output, except that if the PWD environment
>> variable is longer than {PATH_MAX} bytes including the
>> terminating null, it is unspecified whether pwd writes this
>> pathname to standard output or behaves as if the -P option had
>> been specified. Otherwise, the -L option shall behave as the -P
>> option.
>>
>>
>> It mentions "dot-dot" and "dot".
>>
>> It does seems to allow:
>>
>> (cd /; PWD=// pwd -L)
>> //
>> and
>> (cd /home/casper; PWD=/home///casper pwd -L)
>> /home///casper
>>
>>
>> Is this a correct implmentation?
>
>Does the standard cover this at all? It only mentions PWD being set by `cd'
>and initialized by `sh'. If you assign it directly, at least `cd' is
>explicitly unspecified, and since `pwd' is only required to "remove
>unnecessary slash characters" if -P is supplied, I'd say you've left the
>realm of the standard and the implementation can do what it likes.
So you are saying that it would be fine to squish out the additional
slashed in the output? (Not doing anything would be fine, too)
Casper
Re: pwd(1) pwd -L and multple adjacent slashes in $PWD,
>casper@oracle.com wrote, on 14 Apr 2020: >> >> It does seems to allow: >> >> (cd /; PWD=// pwd -L) >> // >> and >> (cd /home/casper; PWD=/home///casper pwd -L) >> /home///casper >> >> >> Is this a correct implmentation? > >Yes. Thanks. >> Is it *required* for the implementation to behave this way? > >No. See the description of PWD under "ENVIRONMENT VARIABLES" on >the pwd page: > >If an application sets or unsets the value of PWD, the behavior of >pwd is unspecified. But if the application sets it to these values and these are proper absolute pathnames of the current working directory, then that is the value we need to print? Casper
pwd(1) pwd -L and multple adjacent slashes in $PWD,
pwd has the -L option:
The following options shall be supported by the implementation:
-L
If the PWD environment variable contains an absolute pathname
of the current directory and the pathname does not contain any
components that are dot or dot-dot, pwd shall write this
pathname to standard output, except that if the PWD environment
variable is longer than {PATH_MAX} bytes including the
terminating null, it is unspecified whether pwd writes this
pathname to standard output or behaves as if the -P option had
been specified. Otherwise, the -L option shall behave as the -P
option.
It mentions "dot-dot" and "dot".
It does seems to allow:
(cd /; PWD=// pwd -L)
//
and
(cd /home/casper; PWD=/home///casper pwd -L)
/home///casper
Is this a correct implmentation?
Is it *required* for the implementation to behave this way?
Casper
Re: [1003.1(2016)/Issue7+TC2 0001318]: Define close-on-fork flag
It seems that this bug changes the following commands about a "wf" or "rf" option for popen(); however, I do not see the additional changes needed for fopen(). Another question I have is this: in fdopen(), Solaris will NOT change the file flags even when "e" is given; this makes sense, I think. So we ignore "e" on fdopen and would do the same for "f"; and I'm assuming that the future standard will include "f" as the "open the file with O_CLOFORK" for fopen() and ilk? Casper On page 1439 line 47807 section popen(), after the bug 411 text: ... any application worried about the potential file descriptor leak will already be using the e modifier. add a new paragraph: Implementations are encouraged to add support for a "wf" mode which creates the pipe as if by calling pipe2() with the O_CLOFORK flag and then clearing FD_CLOFORK for the read side of the pipe. This prevents the write side from leaking into child processes created by other threads, ensuring the child created by popen() will get end-of-file when the parent closes the write side (although the read side can still be leaked). Unfortunately there is no way (short of temporarily preventing other threads from creating child processes, or implementing an atomic create-pipe-and-fork system call) to implement an "rf" mode with the equivalent guarantee that the child created by popen() will be the only writer. Therefore multi-threaded applications that do not have complete control over process creation cannot rely on getting end-of-file on the stream and need to use an alternative method of indicating the end of communications.
Re: Solaris /usr/xpg4/bin/sh builtin handling (Was: About printf %2$s)
>"casper@oracle.com" wrote: >> The only ones that makes sense are "kill" & "print". > >I would say that "print" is not needed since it is not required to be callable >via exec(), since it is a ksh88/ksh93 private builtin. Right "print" is not tested for in the test suite. Casper
Re: Solaris /usr/xpg4/bin/sh builtin handling (Was: About printf %2$s)
>2020-02-03 12:40:45 +0100, Joerg Schilling: >[...] >> > It looks like it's caused by an "optimisation" in its >> > libc:exec*(), so /usr/xpg4/bin/sh and POSIX are not to blame >> > after all. >> >> To which Solaris version does this apply? > >That was 11.4 Yes. >> > $ ksh -c 'printf %d 1+1' >> > printf: 1+1 not completely converted >> >> This is the correct expected output for /usr/bin/printf > >Yes, that's the point, /usr/bin/printf was called instead of ksh >(ksh93 here) and its builtin. > >> > What? ksh's printf does take arithmetic expressions as arguments >> > for %d. >> > >> > $ ksh -c 'printf %d 1+1;' >> > 2 >> > $ ksh -c 'printf %d 1+1' ksh >> > 2 >> > >> > Adding that ; special shell character or an extra argument >> > disables the optimisation. >> >> But this seems to be an easteregg from ksh93. >[...] > >printf %d 1+1 to output 2 is expected in ksh where in most >places where a number is expected, any arithmetic expression is >accepted as well. That behaviour was also copied by zsh. > >It causes all sorts of security headaches as arithmetic expressions can assign >variables (like for IFS=1234567890, PATH=7734) or run arbitrary code (like >a=[$(evil)0]) > >$ a=2 b='a[$(evil)0]' ksh -c 'printf %d b' # /usr/bin/printf run >printf: b expected numeric value >$ a=2 b='a[$(evil)0]' ksh -c 'printf "%d" b' # ksh printf run >ksh: printf: evil: not found [No such file or directory] > >The easteregg here is more solaris libc:exec*() bypassing the >execution of a shell in some cases. Right. I think it may need some sine tuning but I think it is fine to avoid the shell when it is not needed. I was not aware that ksh was all that dangerous; especially as it allows crossing privilege boundaries using environment variable. Not quite as bad as "Shellshock"; not even close. Still another reason to avoid the shell when it not actually needed to start a new command. I'm not sure why we ended up in Solaris with 18 commands which are basically built-in ksh93 commands that make little sense as individual executables: aliascd fc getopts jobs printtest ulimit unalias bg command fg hash kill read type umaskwait It seems that is being tested in XPG4.os/procenv/confstr/ The only ones that makes sense are "kill" & "print". Casper
Re: system() and pthread_atfork()
>This seems like a scenario where you would want system() to require >pthread_atfork() handlers to be called. Aside from that, it seems somewhat >contradictory that system() "shall behave as if a child process were created >using fork()..." but it is undefined if pthread_atfork() handlers are called . > The reason it likely that the implementer of system() and popen() get the freedom to use a more efficient mechanism. In the case of Solaris, we have been using posix_spawn(); originally implemented on top of vfork() & execve(), in Solaris 11.4 it is an actual system call. No call to fork() even under the covers. The vfork() used before also did not call the pthread_atfork() handlers either. If you have control over the callers of system(), you could replace those with posix_spawn() and have posix_spawn attributes in place to close the specific file descriptors. Casper
Re: Environment of expansions and visibility of side-effect assignments
>On Solaris, vfork() is 3x faster than fork(), This depends very much on application. In Solaris, vfork() is more or less O(1) where fork() is a O(n) where "n" is the size of the address space: each r/w page which isn't shared needs to be marked "read-only" so the first modification clones the page to a writable copy. With shared library and the dynamic linker, there is very little that you can do between vfork() to exec/_exit in the child. The current Solaris implementation of posix_spawn() does use vfork() and it is known that its use is safe. For others this is less so. Ok, vfork() isn't completely O(1): it needs to halt all the other threads executing in the same address space, basically it stops to world Casper
Re: [1003.1(2016)/Issue7+TC2 0001142]: pread(2) and pwrite(2) should be async-signal-safe
>-- > (0003753) shware_systems (reporter) - 2017-06-06 12:14 > http://austingroupbugs.net/view.php?id=1142#c3753 >-- >While this looks reasonable, the restriction on pread() and pwrite() of not >disturbing the seek position is problematic. It means an effective >dup();lseek();read() or write();close() sequence occurs on each invoke. This doesn't make sense: dup() creates a file pointer with: osame file pointer (that is, both file descriptors share one file pointer) lseek() on a dup()'ed file will move the lseek on the original file pointer as well. (That makes it possible to write an "lseek(1)" utility which can be used to change the file pointer for inherited file descriptors) Casper
