FreeBSD source tree https://cgit-dev.freebsd.org/src-test/atom?h=main 2020-09-01T13:19:15Z 2020-09-01T13:19:15Z Jilles Tjoelker jilles@FreeBSD.org 2020-09-01T13:19:15Z urn:sha1:ccd0a51fda561d10e091926a83e5bca0e6f41d6d POSIX is pretty clear that command -v, command -V and type shall write absolute pathnames. Therefore, we need to prepend the current directory's name to relative pathnames. This can happen either when PATH contains a relative pathname or when the operand contains a slash but is not an absolute pathname. 2020-08-28T15:35:45Z Jilles Tjoelker jilles@FreeBSD.org 2020-08-28T15:35:45Z urn:sha1:1cffe8b812e5efda80d7c68dab86d2e1906ef088 If job control is not enabled, a background job (... &) ignores SIGINT and SIGQUIT, but this can be reverted using the trap builtin in the same shell environment. Using the set builtin to change options would also revert SIGINT and SIGQUIT to their previous dispositions. This broke due to r317298. Calling setsignal() reverts the effect of ignoresig(). Reported by: bdrewery MFC after: 1 week 2020-06-28T21:33:08Z Jilles Tjoelker jilles@FreeBSD.org 2020-06-28T21:33:08Z urn:sha1:40276ff30e343cfc83b4c4c6293981f2427cbf8b This reverts r362646. PR: 247559 MFC after: 1 week 2020-06-28T21:15:29Z Jilles Tjoelker jilles@FreeBSD.org 2020-06-28T21:15:29Z urn:sha1:c1602cfd61840305f77b94c876f5fbb59aaec542 When job control is not enabled, the shell ignores SIGINT while waiting for a foreground process unless that process exits on SIGINT. In this case, the foreground process is sleep and it does not exit on SIGINT because the signal is only sent to the shell. Depending on order of events, this could cause the SIGINT to be unexpectedly ignored. On lightly loaded bare metal, the chance of this happening tends to be less than 0.01% but with higher loads and/or virtualization it becomes more likely. Starting the sleep in background and using the wait builtin ensures SIGINT will not be ignored. PR: 247559 Reported by: lwhsu MFC after: 1 week 2020-06-26T09:39:23Z Li-Wen Hsu lwhsu@FreeBSD.org 2020-06-26T09:39:23Z urn:sha1:c707e36ef93ca51e049100b685db42dfb33ef04d PR: 238870 Sponsored by: The FreeBSD Foundation 2020-06-14T19:41:24Z Jilles Tjoelker jilles@FreeBSD.org 2020-06-14T19:41:24Z urn:sha1:7312c97fa4611ccecff9122d6e4e8681b0539679 If job control is not enabled, background commands shall ignore SIGINT and SIGQUIT, and it shall be possible to override that ignore in the same shell. MFC after: 1 week 2020-05-30T16:00:49Z Jilles Tjoelker jilles@FreeBSD.org 2020-05-30T16:00:49Z urn:sha1:e0f5c1387df23c8c4811f5b24a7ef6ecac51a71a Austin Group bugs #1226 and #1250 changed the requirements for shell scripts without #! (POSIX does not specify #!; this is about the shell execution when execve(2) returns an [ENOEXEC] error). POSIX says we shall allow execution if the initial part intended to be parsed by the shell consists of characters and does not contain the NUL character. This allows concatenating a shell script (ending with exec or exit) and a binary payload. In order to reject common binary files such as PNG images, check that there is a lowercase letter or expansion before the last newline before the NUL character, in addition to the check for the newline character suggested by POSIX. 2020-05-16T16:29:23Z Jilles Tjoelker jilles@FreeBSD.org 2020-05-16T16:29:23Z urn:sha1:6bc7175f315bd4e2c334d60ee3364cbff63574f1 The shell maintains a count of the number of times SIGINT processing has been disabled via INTOFF, so SIGINT processing resumes when all disables have enabled again (INTON). If an error occurs in a vfork() child, the processing of the error enables SIGINT processing again, and the INTON in vforkexecshell() causes the count to become negative. As a result, a later INTOFF may not actually disable SIGINT processing. This might cause memory corruption if a SIGINT arrives at an inopportune time. As of r360452, it causes the shell to abort when it would unsafely allocate or free memory in certain ways. Note that various places such as errors in non-special builtins unconditionally reset the count to 0, so the problem might still not always be visible. PR: 246497 Reported by: jbeich MFC after: 2 weeks 2020-05-12T21:59:21Z Jilles Tjoelker jilles@FreeBSD.org 2020-05-12T21:59:21Z urn:sha1:1bb4b6a76af6d04fe9d64ddad72fab84c0c84687 2019-12-30T21:32:55Z Jilles Tjoelker jilles@FreeBSD.org 2019-12-30T21:32:55Z urn:sha1:2a55bade0ed3e08a8c4f922df0ecf67d1ee32f53 If executing a file fails with an [ENOEXEC] error, the shell executes the file as a shell script, except that this execution may instead result in an error message if the file is binary. Per a recent Austin Group interpretation, we will need to change this to allow a concatenation of a shell script and a binary payload. See Austin Group bugs #1226 and #1250. MFC after: 1 week