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
When -H is specified, for kernel threads the command is formatted as
"<proc name>/<td name>" and truncated to MAXCOMLEN. But each of the
proc name and td name may be up to MAXCOMLEN bytes in length.
Also handle the ki_moretdname field to ensure that the full thread name
gets printed. This is already handled correctly when formatting for
"-o tdname".
Reported by: freqlabs
Reviewed by: freqlabs
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25840
I've always found this a little bit confusing:
> sh
$ ^D> sh
$ ^D>
Reviewed by: 0mp, jilles
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25813
realtime priorities
The current `ps -axO rtprio' show threads running at interrupt
priority such as the [intr] thread as '1:48' and threads running
at kernel priority such as [pagedaemon] as normal:4294967260.
This change shows [intr] as intr:48 and [pagedaemon] as kernel:4.
Reviewed by: kib
MFC after: 1 week (together with -r362369)
Differential Revision: https://reviews.freebsd.org/D25660
INTOFF postpones SIGINT processing and INTON enables it again. This is
important so an interactive shell can return to the top level prompt when
Ctrl+C is pressed.
Given that INTON is automatically done when a builtin completes, the part
where onsig() ignores suppressint when in_dotrap is true is both unnecessary
and unsafe. If the trap is for some other signal than SIGINT, arbitrary code
could have been interrupted.
Historically, INTOFF remained in effect for longer.
Reviewed by: bdrewery
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25270
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
MFC after: 7 days
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
This flag will now show the processor number on which a process is running.
This change was inspired by PR129965. Initially I didn't think that the
patch attached to it was correct -- it sacrificed ki_estcpu use in "cpu"
for ki_lastcpu and I thought that the old functionality should be kept and
the new (cpu#) one added to it. But I've since discovered that ki_estcpu is
sched_4bsd-specific. What's worse, it represents the same thing as
ki_pctcpu, except ki_pctcpu is universal -- so "%cpu" has been using it
successfully. Therefore, I've decided to replace information based on
ki_estcpu with information based on ki_oncpu/ki_lastcpu.
Key parts of the code and manual changes were borrowed from top(1).
PR: 129965
Reported by: Nikola Knežević
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25377
Fix the rtprio option that for some reason was progessively becoming an
option showing the priority class of threads. In particular:
- use the constants defined in sys/sys/rtprio.h instead of those defined in
sys/sys/priority.h: this helps making clearer that the code actually is
about realtime priorities and not standard scheduler priorities;
- remove the PRI_ITHD case that has nothing to do with realtime priorities;
- convert the priority levels to realtime priority levels using the same
formulas used for pri_to_rtp function in sys/kern/kern_resource.c.
- remove outdated note "101 = not a realtime process" in the man page and
replace it with a more useful reference to man 1 rtprio.
Approved by: src (mckusick), manpages (bcr), gerald (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25266
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
Use %hs (locale-based encoding) instead of %s (UTF-8) format for
strings that are expected to be in current locale encoding (date/time,
process names/argument list).
PR: 241491
Reviewed by: phil
Differential Revision: https://reviews.freebsd.org/D22160
FreeBSD DD utility has not had support for the O_DIRECT flag, which
is useful to bypass local caching, e.g. for unconditionally issuing
NFS IO requests during testing.
Reviewed by: rgrimes (mentor)
Approved by: rgrimes (mentor, blanket)
MFC after: 3 weeks
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D25066
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
PR: 246412
Reviewed by: mckusick, kib, emaste, jilles, cy, phk, imp (all previous)
Reviewed by: rgrimes (latest version)
MFC after: 1 month (note the MFC plan mentioned above)
Relnotes: absolutely, but will amend previous RELNOTES entry
Differential Revision: https://reviews.freebsd.org/D24596
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.
Highlights:
- CLICOLOR in the environment should imply --color=auto to maintain
compatibility with historical behavior
- -G should set CLICOLOR and imply --color=auto
The manpage has been updated to draw the connection between -G and --color;
the former is in-fact a sort of compromise between --color=always and
--color=auto, where we'll output color regardless of the environment lacking
CLICOLOR/COLORTERM assuming stdout is a tty.
X-MFC-With: r361318
The regression is in-fact that I flipped the default from never to auto. The
incorrect impression was based on an alias that I failed to notice,
installed by the Linux distribution that I used for testing compatibility
here. Users that want the old default should be doing so with a shell alias
as is done elsewhere, rather than making this decision in ls(1).
Many thanks to rgrimes for pointing out the alias that I clearly overlooked
that resulted in this; if you despised colors in your terminal from this,
consider buying him a beer at the next venue that you see him at.
MFC after: 1 week
Relnotes: yes
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
Initially it seemed that there were multiple possible ways to do it.
Processing option -p could conditionally add selected processes and
their descendants to the list for further work, but it is not guaranteed
to know whether the -d option has been used or not, and it also doesn't
have access to the process list just yet.
There is also descendant_sort() which has access to all possibly needed
information, but serves the purely post-processing purpose of sorting
output.
Then there is the loop that uses invocation information and full process
list to create a list of processes for final display. It seems the most
natural place to implement this, but indeterminate state of the process
list and volatility of the final list that is being created obstruct
adding an elegant search for all elements of process descendancy trees.
So I opted for adding another loop, just before the one I mentioned
above. For all selected processes it conditionally adds direct
descendants to the end of this list of selected processes.
Possible usage:
* ps -auxd -p $$
* ps -auxd -p 1
* while x=$(pgrep svnlite); do clear; ps auxd -p $x; sleep 2; done
* ps -auxd -p `pgrep make`
Reviewed by: kevans, kaktus (earlier version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24380
As I noted in https://reviews.freebsd.org/D22756, INTOFF should be in effect
when calling ckmalloc/ckrealloc/ckfree to avoid memory leaks and double
frees. Therefore, change the functions to check if INTOFF is in effect
instead of applying it.
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D24599
r360139 made compiling with NO_HISTORY work. This #define does not remove
the fc and bind builtins completely but makes them always write an error
message.
However, there was also some code in builtins.def and mkbuiltins to remove
the fc builtin entirely (but not the bind builtin). The additional build
system complication to make this work seems not worth it, so remove that
code.
mips-gcc for mips32 was complaining that c was potentially used before
being set. Setting it to 0 before calling fdgetsc() looks like the right
thing to do in this instance; there's an explicit check for c == 0 later
on.
Tested: mips-gcc mips32 build, running /bin/sh on mips32
el is declared extern in myhistedit.h and defined in histedit.c. Remove the
duplicate definition in input.c to appease the -fno-common build.
-fno-common will become the default in GCC10/LLVM11.
MFC after: 3 days
Specifically, any system with a 32-bit size_t; -residue is calculated as a
32-bit *then* promoted to the 64-bit off_t and the result is ultimately
wrong. This resulted in what would appear to be truncated output, as only
the first line would be read.
Correct it by just making residue an off_t to begin with, since this is what
lseek will take anyways.
Reported by: antoine, dim
Triaged by: cem
Tested by: kevans
X-MFC-With: r358152
fd.
The read built-in command calls read(2) with a 1-byte buffer because
newline characters need to be detected even on a byte stream which
comes from a non-seekable file descriptor. Because of this, the
following script calls >6,000 read(2) to show a 6KiB file:
while read IN; do echo "$IN"; done < /COPYRIGHT
When the input byte stream is seekable, it is possible to read a data
block and then reposition the file pointer to where a newline
character found. This change adds a small buffer to do this and
reduces the number of read(2) calls.
Theoretically, multiple built-in commands reading the same seekable
byte stream in a single pipe chain can share the buffer. However,
this change just makes a single invocation of the read built-in
allocate a buffer and deallocate it every time for simplicity.
Although this causes read(2) to read the same regions multiple times,
the performance penalty should be small compared to the reduction of
read(2) calls.
Reviewed by: jilles
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D23747
`cat -l` is needed during the installworld phase and other system's cat
don't support that flag. To avoid portability issues when compiling on
Linux/macOS (such as the the direct access to &fp->_mbstate), we
disable the entire multibyte support when building as a boostrap tool.
Reviewed By: brooks, emaste
Differential Revision: https://reviews.freebsd.org/D13939
If getcwd() failed earlier on but later succeeded in the pwd builtin,
there was no INTOFF protection between calling savestr() and storing its
result.
It is quite rare for getcwd() to fail, and rarer for it to succeed later in
the same directory.
Found via code inspection for changing ckmalloc() and similar to assert
INTOFF protection instead of applying it directly (which protects against
corrupting malloc's internal state but allows memory leaks or double frees).
MFC after: 1 week
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
Update a bunch of Makefile.depend files as
a result of adding Makefile.depend.options files
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22494
Leaf directories that have dependencies impacted
by options need a Makefile.depend.options file
to avoid churn in Makefile.depend
DIRDEPS for cases such as OPENSSL, TCP_WRAPPERS etc
can be set in local.dirdeps-options.mk
which can add to those set in Makefile.depend.options
See share/mk/dirdeps-options.mk
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22469
Normally, count=n means read(2) will be called n times on the input to dd. If
the read() returns short, as may happen when reading from a pipe, fewer bytes
will be copied from the input. With conv=sync the buffer is padded with zeros
to fill the rest of the block.
iflag=fullblock causes dd to continue reading until the block is full, so that
count=n means n full blocks are copied. This flag is compatible with illumos
and GNU dd and is used in the ZFS test suite.
Submitted by: Ryan Moeller
Reviewed by: manpages, mmacy@
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D21441
Sets the O_FSYNC flag on the output file. oflag=fsync and oflag=sync are
synonyms just as O_FSYNC and O_SYNC are synonyms. This functionality is
intended to improve portability of dd commands in the ZFS test suite.
Submitted by: Ryan Moeller
Reviewed by: manpages, mmacy@
MFC after: 1 week
Sponsored by: iXsytems, Inc.
Differential Revision: https://reviews.freebsd.org/D21422
close(2) can return errors from previous operations which should not be ignored.
PR: 229616
Submitted by: Thomas Hurst
Reported by: Thomas Hurst
Reviewed by: mmacy@
Obtained from: Ryan Moeller
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21376
The fdatasync flag performs an fdatasync(2) on the output file before closing it.
This will be useful for the ZFS test suite.
Submitted by: Ryan Moeller
Reviewed by: manpages, mmacy@
MFC after: 1 week
Sponsored by: iXSystems, Inc.
Differential Revision: https://reviews.freebsd.org/D21373
The default package use to be FreeBSD-runtime but it should only contain
binaries and libs enough to boot to single user and repair the system, it
is also very handy to have a package that can be tranform to a small mfsroot.
So create a new package named FreeBSD-utilities and make it the default one.
Also move a few binaries and lib into this package when it make sense.
Reviewed by: bapt, gjb
Differential Revision: https://reviews.freebsd.org/D21506
The fsync flag performs an fsync(2) on the output file before closing it.
This will be useful for the ZFS test suite.
Submitted by: ryan@ixsystems.com
Reviewed by: jilles@, imp@
MFC after: 1 week
Sponsored by: iXsystems, Inc.
The RELEASE_CRUNCH check is redundant here. We don't need it for releases
anymore, and picobsd can control this more directly without making it a special
case.
asserted. Some development boards for example will reset on DTR,
and some radio interfaces will transmit on RTS.
This patch allows "stty -f /dev/ttyu9.init -rtsdtr" to prevent
RTS and DTR from being asserted on open(), allowing these devices
to be used without problems.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D20031
newvers.sh has supported a variable setting only mode, use that in
preference to grep to future proof this script from changes there.
Differential Revision: https://reviews.freebsd.org/D19849
Since D19668 was done, new users of the -n flag have surfaced. Parse
and ignore it on the command line until they can be updated.
Suggested by: rgrimes (in D19668).
These were used to set dst flag and minutes west of UTC
respectively. These are obsolete and have been removed form the
kernel. These existed primarily to faithfully emulate early
Unix ABIs that have been removed from FreeBSD.
Reviewed by: jbh@, brooks@
Differential Revision: https://reviews.freebsd.org/D19550
The pipefail option allows checking the exit status of all commands in a
pipeline more easily, at a limited cost of complexity in sh itself. It works
similarly to the option in bash, ksh93 and mksh.
Like ksh93 and unlike bash and mksh, the state of the option is saved when a
pipeline is started. Therefore, even in the case of commands like
A | B &
a later change of the option does not change the exit status, the same way
(A | B) &
works.
Since SIGPIPE is not handled specially, more work in the script is required
for a proper exit status for pipelines containing commands such as head that
may terminate successfully without reading all input. This can be something
like
(
cmd1
r=$?
if [ "$r" -gt 128 ] && [ "$(kill -l "$r")" = PIPE ]; then
exit 0
else
exit "$r"
fi
) | head
PR: 224270
Relnotes: yes
SVN r342880 was designed to fix $((-9223372036854775808)) and things like
$((0x8000000000000000)) but also broke error detection for values of
variables without dollar sign ($((x))).
For compatibility, overflow in plain literals continues to be ignored and
the value is clamped to the boundary (except 9223372036854775808 which is
changed to -9223372036854775808).
Reviewed by: se (although he would like error checking to be removed)
MFC after: 2 weeks
X-MFC-with: r342880
Differential Revision: https://reviews.freebsd.org/D18926
The rest of this stuff is still to be discussed, but I think at this
point we have the agreement that the aliases should go.
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
there's no need to even mention it in shell rc files. Not that it's wrong;
just pointless and somewhat misleading.
Reviewed by: jilles
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D18809
The libedit "fout" output must be sent to fd 2 since it contains prompts
that POSIX says must be sent to fd 2. However, the libedit "ferr" output
receives error messages such as from "bind" that make no sense to send to fd
1.
results between an expression that refers to a variable by name and the
same expression that includes the same variable by value.
Submitted by: se@
MFC after: 1 week
if -z option also used.
Recommend the use of zip(1) if compressed files of predictable size needed.
PR: docs/41089
Submitted by: Sevan Janiyan
Reported by: areilly@bigpond.net.au
While here, pet igor
Reviewed by: bcr
Differential Revision: https://reviews.freebsd.org/D18686
with macro based around memcmp(). The latter is expected to be some
8 times faster on a modern 64-bit architectures.
In practice, throughput of doing conv=sparse from /dev/zero to /dev/null
went up some 5-fold here from 1.9GB/sec to 9.7GB/sec with this change
(bs=128k).
MFC after: 2 weeks
If word in ${param?word} is missing, the shell shall write a default error
message. So expanding ${param?} when param is not set should write an error
message like
sh: param: parameter not set
This was broken by r316417.
PR: 233585
-P was introduced in 4.4BSD-Lite2 around 1994. It overwrote file contents
with a pass of 0xff, 0x00, then 0xff, in a low effort attempt to "really
delete" files.
It has no user-visible effect; at the end of the day, the file is unlinked via
the filesystem. Furthermore, the utility of overwriting files with patterned
data is extremely limited due to caveats at every layer of the stack[0] and
therefore mostly futile. At the least, three passes is likely wasteful on
modern hardware[1]. It could also be seen as a violation of the "Unix
Philosophy" to do one thing per tiny, composable program.
Since 1994, FreeBSD has left it alone; OpenBSD replaced it with a single
pass of arc4random(3) output in 2012[2]; and NetBSD implemented partial, but
explicitly incomplete support for U.S. DoD 5220.22-M, "National Industrial
Security Program Operating Manual" in 2004[3].
NetBSD's enhanced comment above rm_overwrite makes a strong case for removing
the flag entirely:
> This is an expensive way to keep people from recovering files from your
> non-snapshotted FFS filesystems using fsdb(8). Really. No more.
>
> It is impossible to actually conform to the exact procedure given in
> [NISPOM] if one is overwriting a file, not an entire disk, because the
> procedure requires examination and comparison of the disk's defect lists.
> Any program that claims to securely erase *files* while conforming to the
> standard, then, is not correct.
>
> Furthermore, the presence of track caches, disk and controller write
> caches, and so forth make it extremely difficult to ensure that data have
> actually been written to the disk, particularly when one tries to repeatedly
> overwrite the same sectors in quick succession. We call fsync(), but
> controllers with nonvolatile cache, as well as IDE disks that just plain lie
> about the stable storage of data, will defeat this.
>
> [NISPOM] requires physical media destruction, rather than any technique of
> the sort attempted here, for secret data.
As a first step towards evental removal, make it a placebo. It's not like
it was serving any security function. It is not defined in or mentioned by
POSIX.
If you are security conscious and need to erase your files, use a
woodchipper. At a minimum, the entire disk needs to be overwritten, not
just one file.
[0]: https://www.ru.nl/publish/pages/909282/draft-paper.pdf
[1]: https://commons.erau.edu/cgi/viewcontent.cgi?article=1131&context=jdfsl
[2]: https://github.com/openbsd/src/commit/7c5c57ba81b5fe8ff2d4899ff643af18c
[3]: https://github.com/NetBSD/src/commit/fdf0a7a25e59af958fca1e2159921562cd
Reviewed by: markj, Daniel O'Connor <darius AT dons.net.au> (previous version)
Differential Revision: https://reviews.freebsd.org/D17906
The difference between EXERROR and EXEXEC was that EXEXEC passed along
exitstatus and EXERROR set exitstatus to 2 in the handling code.
By changing the places that raised EXERROR to set exitstatus to 2, the
handling of EXERROR and EXEXEC becomes the same.
You should not be using DES. You should not have been using DES for the
past 30 years.
The ed DES-CBC scheme lacked several desirable properties of a sealed
document system, even ignoring DES itself. In particular, it did not
provide the "integrity" cryptographic property (detection of tampering), and
it treated ASCII passwords as 64-bit keys (instead of using a KDF like
scrypt or PBKDF2).
Some general approaches ed(1) users might consider to replace the removed
DES mode:
1. Full disk encryption with something like AES-XTS. This is easy to
conceptualize, design, and implement, and it provides confidentiality for
data at rest. Like CBC, it lacks tampering protection. Examples include
GELI, LUKS, FileVault2.
2. Encrypted overlay ("stackable") filesystems (EncFS, PEFS?, CryptoFS,
others).
3. Native encryption at the filesystem layer. Ext4/F2FS, ZFS, APFS, and
NTFS all have some flavor of this.
4. Storing your files unencrypted. It's not like DES was doing you much
good.
If you have DES-CBC scrambled files produced by ed(1) prior to this change,
you may decrypt them with:
openssl des-cbc -d -iv 0 -K <key in hex> -in <inputfile> -out <plaintext>
Reviewed by: allanjude, bapt, emaste
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D17829
- Use Xr to reference other manual pages.
- Reference execve(2) instead of exec(2) as exec(2) does not exist.
- Remove the deprecated "Tn" macro.
- Improve the formatting of the etime description.
Reviewed by: bcr
Approved by: krion (mentor, implicit), mat (mentor, implicit)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D17780
They only make sense in the context of directory ACLs, and attempting
to set them on regular files results in errors, causing a recursive
setfacl invocation to abort.
This is derived from patches by Shawn Webb <shawn.webb@hardenedbsd.org>
and Mitchell Horne <mhorne063@gmail.com>.
PR: 155163
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15061
