FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F12.2 2020-09-03T13:22:09Z 2020-09-03T13:22:09Z Gordon Bergling gbe@FreeBSD.org 2020-09-03T13:22:09Z urn:sha1:a51d4ce4f6705e491e90446efead7e79fba43117 - Update the POSIX references for non-standard ls(1) options - Simplify the STANDARDS section by mention both supported POSIX versions Verified by checking [1]. [1] https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/toc.htm PR: 140435 (based on) Submitted by: Dan Lukes <dan at obluda dot cz> Reviewed by: hrs, bcr Approved by: hrs, bcr Differential Revision: https://reviews.freebsd.org/D26210 2020-09-02T17:46:56Z Ed Maste emaste@FreeBSD.org 2020-09-02T17:46:56Z urn:sha1:6bc23dcb8bdd228a2c2dffd9f9940a7f50a96f87 PR: 248918 2020-08-04T00:28:06Z Mark Johnston markj@FreeBSD.org 2020-08-04T00:28:06Z urn:sha1:0b0a602ec97d2e93b4128e06bd2c14dc5544b608 ps(1): Fix formatting of the "command" field for kernel threads. 2020-08-03T06:54:04Z Piotr Pawel Stefaniak pstef@FreeBSD.org 2020-08-03T06:54:04Z urn:sha1:d919eeac2ba6590ba46ebad99770b68add85a0bd 2020-07-26T09:47:01Z Mateusz Piotrowski 0mp@FreeBSD.org 2020-07-26T09:47:01Z urn:sha1:f79e2a0cb6148abcf68d64110b3db64848a0ce36 Fix description of the "\$" sequence for PS1 The manual page documents "\$" to expand to either "$" or "#" followed by a single space. In reality, the single space character is not appended. PR: 247791 Submitted by: kd-dev@pm.me 2020-07-25T11:57:39Z Piotr Pawel Stefaniak pstef@FreeBSD.org 2020-07-25T11:57:39Z urn:sha1:73dee37eaaaaaca535e262582773f04887cb7ef6 r342577 Make sh(1) collapse $HOME into "~" in PS1 r342576 Simplify the way we set the default sh(1) PS1 r342645 Add current working directory to the default sh prompt r342812 Give sh(1) a proper default prompt instead of just "$". r342881 Make sh(1) recognize the default $HOME r343231 Don't mess with BLOCKSIZE in shell startup files r343399 Make sh(1) support \u in PS1 2020-07-21T23:23:08Z Kirk McKusick mckusick@FreeBSD.org 2020-07-21T23:23:08Z urn:sha1:ffe854ff243d4c4223c58f49043d5ee36f5f7b03 Refinement of /bin/ps rtprio output 2020-07-09T17:43:25Z Jilles Tjoelker jilles@FreeBSD.org 2020-07-09T17:43:25Z urn:sha1:37c3f7c0da1321dc80ecd72bb34a5e4f612581c8 PR: 247559 2020-07-09T17:42:31Z Jilles Tjoelker jilles@FreeBSD.org 2020-07-09T17:42:31Z urn:sha1:a7e752dadeb96abf63ca6c672b1ae89bec3199b1 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 2020-07-08T18:29:06Z Kyle Evans kevans@FreeBSD.org 2020-07-08T18:29:06Z urn:sha1:09141153f5c2706740b88c214be0a4c8b2b3f1ff This MFC is in accordance with the original MFC plan outlined in the commit message for r361798, appearing in full (with exception to metadata) below. To summarize: this MFC only merges back the sysctl with a default disallow policy, as in head, to ensure we hit any issues quickly but in a fashion that end users can easily revert. Interested parties can flip the security.bsd.allow_read_dir sysctl back to 1 to fully honor the previous behavior of allowing read(2) of any dir, filesystem permitting. r361798: vfs: add restrictions to read(2) of a directory [1/2] Historically, we've allowed read() of a directory and some filesystems will accommodate (e.g. ufs/ffs, msdosfs). From the history department staffed by Warner: <<EOF pdp-7 unix seemed to allow reading directories, but they were weird, special things there so I'm unsure (my pdp-7 assembler sucks). 1st Edition's sources are lost, mostly. The kernel allows it. The reconstructed sources from 2nd or 3rd edition read it though. V6 to V7 changed the filesystem format, and should have been a warning, but reading directories weren't materially changed. 4.1b BSD introduced readdir because of UFS. UFS broke all directory reading programs in 1983. ls, du, find, etc all had to be rewritten. readdir() and friends were introduced here. SysVr3 picked up readdir() in 1987 for the AT&T fork of Unix. SysVr4 updated all the directory reading programs in 1988 because different filesystem types were introduced. In the 90s, these interfaces became completely ubiquitous as PDP-11s running V7 faded from view and all the folks that initially started on V7 upgraded to SysV. Linux never supported this (though I've not done the software archeology to check) because it has always had a pathological diversity of filesystems. EOF Disallowing read(2) on a directory has the side-effect of masking application bugs from relying on other implementation's behavior (e.g. Linux) of rejecting these with EISDIR across the board, but allowing it has been a vector for at least one stack disclosure bug in the past[0]. By POSIX, this is implementation-defined whether read() handles directories or not. Popular implementations have chosen to reject them, and this seems sensible: the data you're reading from a directory is not structured in some unified way across filesystem implementations like with readdir(2), so it is impossible for applications to portably rely on this. With this patch, we will reject most read(2) of a dirfd with EISDIR. Users that know what they're doing can conscientiously set bsd.security.allow_read_dir=1 to allow read(2) of directories, as it has proven useful for debugging or recovery. A future commit will further limit the sysctl to allow only the system root to read(2) directories, to make it at least relatively safe to leave on for longer periods of time. While we're adding logic pertaining to directory vnodes to vn_io_fault, an additional assertion has also been added to ensure that we're not reaching vn_io_fault with any write request on a directory vnode. Such request would be a logical error in the kernel, and must be debugged rather than allowing it to potentially silently error out. Commented out shell aliases have been placed in root's chsrc/shrc to promote awareness that grep may become noisy after this change, depending on your usage. A tentative MFC plan has been put together to try and make it as trivial as possible to identify issues and collect reports; note that this will be strongly re-evaluated. Tentatively, I will MFC this knob with the default as it is in HEAD to improve our odds of actually getting reports. The future priv(9) to further restrict the sysctl WILL NOT BE MERGED BACK, so the knob will be a faithful reversion on stable/12. We will go into the merge acknowledging that the sysctl default may be flipped back to restore historical behavior at *any* point if it's warranted. [0] https://www.freebsd.org/security/advisories/FreeBSD-SA-19:10.ufs.asc r361800: RELNOTES and UPDATING: Document the new policy on read(2) of dirfd These changes have been completely flushed as of r361799; note it. PR: 246412 Relnotes: yes 100%