Rendering of execle was missing a comma between the NULL argument and envp.
For unclear reasons, POSIX' definition of these routines comments out the
mandatory trailing NULL argument. That seems unnecessary and probably
(reasonably) confuses mdoc.
For unclear reasons, POSIX' definition of these routines spells NULL as
"(char *)0." This is needlessly unclear. One guess might be that POSIX
targets more exotic computer architectures than FreeBSD does. Fortunately,
there is no such problem on any reasonable platform for FreeBSD to support.
Spell NULL as NULL.
The comma was probably removed in r117204 while the comment and creative
spelling of NULL were added in r116537 (both 15 years ago).
data from /etc/passwd rather than /etc/master.passwd.
The libc getpwent(3) and related functions automatically read master.passwd
when run by root, or passwd when run by a non-root user. When run by non-
root, getpwent() copes with the missing data by setting the corresponding
fields in the passwd struct to known values (zeroes for numbers, or a
pointer to an empty string for literals). When libutil's pw_scan(3) was
used to parse a line without the root-accessible data, it was leaving
garbage in the corresponding fields.
These changes rename the static pw_init() function used by getpwent() and
friends to __pw_initpwd(), and move it into pw_scan.c so that common init
code can be shared between libc and libutil. pw_scan(3) now calls
__pw_initpwd() before __pw_scan(), just like the getpwent() family does, so
that reading an arbitrary passwd file in either format and parsing it with
pw_scan(3) returns the same results as getpwent(3) would.
This also adds a new pw_initpwd(3) function to libutil, so that code which
creates passwd structs from scratch in some manner that doesn't involve
pw_scan() can initialize the struct to the values expected by lots of
existing code, which doesn't expect to encounter NULL pointers or garbage
values in some fields.
Some applications, notably PostgreSQL, want to call setproctitle()
very often. It's slow. Provide an alternative cheap way of updating
process titles without making any syscalls, instead requiring other
processes (top, ps etc) to do a bit more work to retrieve the data.
This uses a pre-existing code path inherited from ancient BSD, which
always did it that way.
Submitted by: Thomas Munro
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D16111
- Move CSRG IDs into __SCCSID().
- When a file has been copied, consistently use 'From: <tag>' for strings
referencing the version of the source file copied from in the license
block comment.
- Some of the 'From:' tags were using $FreeBSD$ that was being expanded on
each checkout. Fix those to hardcode the FreeBSD tag from the file that
was copied at the time of the copy.
- When multiple strings are present list them in "chronological" order,
so CSRG (__SCCSID) before FreeBSD (__FBSDID). If a file came from
OtherBSD and contains a CSRG ID from the OtherBSD file, use the order
CSRG -> OtherBSD -> FreeBSD.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D15831
The handbooks are not installed there anymore. While here, improve the
URLs markup a bit.
Reviewed by: allanjude@
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D15793
Originally, on the VAX exect() enable tracing once the new executable
image was loaded. This was possible because tracing was controllable
through user space code by setting the PSL_T flag. The following
instruction is a system call that activated tracing (as all
instructions do) by copying PSL_T to PSL_TP (trace pending). The
first instruction of the new executable image would trigger a trace
fault.
This is not portable to all platforms and the behavior was replaced with
ptrace(PT_TRACE_ME, ...) since FreeBSD forked off of the CSRG repository.
Platforms either incorrectly call execve(), trigger trace faults inside
the original executable, or do contain an implementation of this
function.
The exect() interfaces is deprecated or removed on NetBSD and OpenBSD.
Submitted by: Ali Mashtizadeh <ali@mashtizadeh.com>
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D14989
mdoc treats verbatim quotes in .Dl as a string delimiter and does
not pass them to the rendered output. Use special char \*q to specify
double quote
PR: 216755
MFC after: 3 days
This caching has existed since the CSRG import, but serves no obvious
purpose. Sure, setlogin() is called rarely, but calls to getlogin()
should also be infrequent. The required invalidation was not
implemented on aarch64, arm, mips, amd riscv so updates would never
occur if getlogin() was called before setlogin().
Reported by: Ali Mashtizadeh <ali@mashtizadeh.com>
Reviewed by: kib
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D14965
With r332099 changing syslogd(8) to parse RFC 5424 formatted syslog
messages, go ahead and also change the syslog(3) libc function to
generate them. Compared to RFC 3164, RFC 5424 has various advantages,
such as sub-second precision for log entry timestamps.
As this change could have adverse effects when not updating syslogd(8)
or using a different system logging daemon, add a notice to UPDATING and
increase __FreeBSD_version.
Differential Revision: https://reviews.freebsd.org/D14926
On older kernels, when userspace program disables SIGSYS, catch ENOSYS and
emulate getrandom(2) syscall with the kern.arandom sysctl (via existing
arc4_sysctl wrapper).
Special care is taken to faithfully emulate EFAULT on NULL pointers, because
sysctl(3) as used by kern.arandom ignores NULL oldp. (This was caught by
getentropy(3) ATF tests.)
Reported by: kib
Reviewed by: kib
Discussed with: delphij
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D14785
The general idea here is to provide userspace programs with well-defined
sources of entropy, in a fashion that doesn't require opening a new file
descriptor (ulimits) or accessing paths (/dev/urandom may be restricted
by chroot or capsicum).
getrandom(2) is the more general API, and comes from the Linux world.
Since our urandom and random devices are identical, the GRND_RANDOM flag
is ignored.
getentropy(3) is added as a compatibility shim for the OpenBSD API.
truss(1) support is included.
Tests for both system calls are provided. Coverage is believed to be at
least as comprehensive as LTP getrandom(2) test coverage. Additionally,
instructions for running the LTP tests directly against FreeBSD are provided
in the "Test Plan" section of the Differential revision linked below. (They
pass, of course.)
PR: 194204
Reported by: David CARLIER <david.carlier AT hardenedbsd.org>
Discussed with: cperciva, delphij, jhb, markj
Relnotes: maybe
Differential Revision: https://reviews.freebsd.org/D14500
POSIX explicitly states that the application must declare union semun.
This makes no sense, but it is what it is. This brings us into line
with Linux, MacOS/Darwin, and NetBSD.
In a ports exp-run a moderate number of ports fail due to a lack of
approprate autotools-like discovery mechanisms or local patches. A
commit to address them will follow shortly.
PR: 224300, 224443 (exp-run)
Reviewed by: emaste, jhb, kib
Exp-run by: antoine
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D14492
nothing - it was checking for ENXIO, which, with devfs, is no longer
returned - and was badly placed anyway, and replaces it with similar
one that works, and is done just before starting getty, instead of being
done when rereading ttys(5).
From the practical point of view, this makes init(8) handle disappearing
terminals (eg /dev/ttyU*) gracefully, without unneccessary getty restarts
and resulting error messages.
Reviewed by: imp@
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14307
According to the getpeereid(3) documentation, on failure the value -1 is
returned and the global variable errno is set to indicate the error. We
were returning the error instead.
Obtained from: Apple's Libc-1244.30.3
MFC after: 5 days
utilities is done by calling gr_addgid() for each group to be
added (usually found by traversing /etc/group) then calling the
setgroups() system call after the group set has been created.
The gr_addgid() function (helpfully?) deduplicates the addition
of group members. So, if you call it to add a group member that
already exists, it is just dropped. Because group[0] is the
effective group-ID and is over-written when a setgid program
is run, The value in group[0] is usually duplicated so that
group value is not lost when a setgid program is run.
Historically this happened because the group value indicated
in the password file also appears in /etc/group (e.g., if you
are group staff in the password file, you will also appear in
the staff line in /etc/group). But, with the addition of the
deduplication, the attempt to add group staff was lost because
it already appeared in group[0]. So, the fix is to deduplicate
starting from group[1] which allows a duplicate of the entry in
group[0], but not in later entries.
There is some confusion about the setgroups system call because in
BSD it has (always) set the entire group including the egid group
(in group[0]). However, in Linux, it skips over group[0] and starts
setting from group[1]. See this comment from linux_setgroups:
/*
* cr_groups[0] holds egid. Setting the whole set from
* the supplied set will cause egid to be changed too.
* Keep cr_groups[0] unchanged to prevent that.
*/
To make it clear what the BSD setgroups system call does, I
added the following paragraph to the setgroups(2) manual page:
The first entry of the group array (gidset[0]) is used as the effective
group-ID for the process. This entry is over-written when a setgid
program is run. To avoid losing access to the privileges of the
gidset[0] entry, it should be duplicated later in the group array.
By convention, this happens because the group value indicated in the
password file also appears in /etc/group. The group value in the
password file is placed in gidset[0] and that value then gets added a
second time when the /etc/group file is scanned to create the group set.
Reported by: Paul McMath paulm at tetrardus.net
Reviewed by: kib
MFC after: 2 weeks
The daemonfd function is equivalent to the daemon(3) function expect that
arguments are descriptors. For example dhclient(8) which is sandboxed is
unable to open /dev/null to close stdio instead it's allows to fail
daemon(3) function to close the descriptors and then do it explicit in code.
Instead of such hacks we can use now daemonfd.
This API can be also helpful to migrate system to platforms like CheriBSD.
Reviewed by: brooks@, bcr@, jilles@ (earlier version)
Differential Revision: https://reviews.freebsd.org/D13433
There are two versions of variant I of TLS
- ARM and aarch64 uses original version of variant I here TP points to
start of TCB followed by aligned TLS segment. Both TCB and TLS must
be aligned to alignment of TLS section. The TCB[0] points to DTV vector
and DTV values are real addresses (without bias).
- MIPS, PowerPC and RISC-V use modified version of variant I,
where TP points (with bias) to TLS and TCB immediately precedes TLS
without any alignment gap. Only TLS should be aligned. The TCB[0]
points to DTV vector and DTV values are biased by constant value (0x8000)
from real addresses.
Take all this in account when allocating memory for TLS structures.
MFC after: 1 month
Reviewed by: kib, mizhka
Tested by: mizhka(on mips)
Differential Revision: https://reviews.freebsd.org/D13378
Now that the POSIX working group is going to require that basename(3)
and dirname(3) are thread-safe in future revisions of the standard,
there is even less of a need to provide basename_r(3). Remove this
function to prevent people from writing code that only builds on
FreeBSD and Bionic.
Removing this function seems to break exactly one port: sbruno@'s
qemu-user-static. I will send him a pull request on GitHub in a bit.
__FreeBSD_version will not be bumped, as any value from 2017 can be used
to test for the presence of a thread-safe basename(3)/dirname(3).
PR: https://bugs.freebsd.org/224016
Currently each call to telldir() requires a malloc and adds an entry to a
linked list which must be traversed on future telldir(), seekdir(),
closedir(), and readdir() calls. Applications that call telldir() for every
directory entry incur O(n^2) behavior in readdir() and O(n) in telldir() and
closedir().
This optimization eliminates the malloc() and linked list in most cases by
packing the relevant information into a single long. On 64-bit architectures
msdosfs, NFS, tmpfs, UFS, and ZFS can all use the packed representation. On
32-bit architectures msdosfs, NFS, and UFS can use the packed
representation, but ZFS and tmpfs can only use it for about the first 128
files per directory. Memory savings is about 50 bytes per telldir(3) call.
Speedup for telldir()-heavy directory traversals is about 20-30x for one
million files per directory.
Reviewed by: kib, mav, mckusick
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D13385
system calls. Man pages are missing for v2 and v5, so any entries for
those versions were inferred by new implementations of these functions
in libc.
Obtained from: http://www.tuhs.org/cgi-bin/utree.pl
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using mis-identified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
For statically linked binaries, where all relocation are solved by static
linker, the linker expect that offset to TLS section is aligned. Additionaly,
to maintain absolute alignment, TLS TCB should by also aligned.
Obtained from: CheriBSD (initial version)
MFC after: 1 month
Reviewed by: brooks (previous version), kib
Differential Revision: https://reviews.freebsd.org/D12907
one call to sysctl(2) from jemalloc startup code. (That also requires
changes to jemalloc, but I plan to push those to upstream first.)
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D12745
- Teach elf aux vector functions about newly added AT_HWCAP and AT_HWCAP2
vectors.
- Export _elf_aux_info() as new public libc function elf_aux_info(3)
The elf_aux_info(3) should be considered as FreeBSD counterpart of glibc
getauxval() with more robust interface.
Note:
We cannot name this new function as getauxval(), with glibc compatible
interface. Some ports autodetect its existence and then expects that all
Linux specific AT_<*> vectors are defined and implemented.
MFC after: 1 month
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D12743
On Variant I TLS architectures (aarch64, arm, mips, powerpc, and riscv)
the __libc_allocate_tls function allocates thread local storage memory
with calloc(). It then copies initialization data over the portions with
non-zero initial values. Before this change it would then pointlessly
zero the already zeroed remainder of the storage. Unfortunately the
calculation was wrong and it would zero TLS_TCB_SIZE (2*sizeof(void *))
additional bytes.
In practice, this overflow only matters if the TLS segment is sized such
that calloc() allocates a less than TLS_TCB_SIZE extra memory. Even
then, the likely result will be zeroing part of the next bucket. This
coupled with the impact being confined to Tier II platforms means there
will be no security advisory for this issue.
Reviewed by: kib, dfr
Discussed with: security-officer (delphij)
MFC after: 1 week
Found by: CHERI
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D12547
Illumos and Schillix is adopting some of the locale code and our style(9)
sometimes matches the Solaris cstyle, so the changes are also useful as a
way to reduce diffs.
No functional change.
Discussed with: Joerg Schilling
MFC after: 1 week
getmntinfo(3) is designed around a relatively static or slow growing set of
current mounts. It tried to detect a race with somewhat concurrent mount
and re-call getfsstat(2) in that case, looping indefinitely. It also
allocated space for a single extra mount as slop.
In the case where the user has a large number of mounts and is adding them
at a rapid pace, it fell over.
This patch makes two functional changes:
1. Allocate even more slop. Double whatever the last getfsstat(2) returned.
2. Abort and return some known results after looping a few times
(arbitrarily, 3). If the list is constantly changing, we can't guarantee
we return a full result to the user at any point anyways.
While here, add very basic functional tests for getmntinfo(3) to the libc
suite.
PR: 221743
Submitted by: Peter Eriksson <peter AT ifm.liu.se> (earlier version)
Sponsored by: Dell EMC Isilon
In a recent interpretation[1], "\\" shall return a non-zero value
(indicating either no match or an error).
The fix involves a change over r254091 and now the behavior matches the
Sun/IBM/HP closed source implementations and also likely musl libc.
Submitted by: Joerg Schilling <joerg at schily.net>
MFC after: 1 week
[1] http://austingroupbugs.net/view.php?id=806
o Replace __riscv64 with (__riscv && __riscv_xlen == 64)
This is required to support new GCC 7.1 compiler.
This is compatible with current GCC 6.1 compiler.
RISC-V is extensible ISA and the idea here is to have built-in define
per each extension, so together with __riscv we will have some subset
of these as well (depending on -march string passed to compiler):
__riscv_compressed
__riscv_atomic
__riscv_mul
__riscv_div
__riscv_muldiv
__riscv_fdiv
__riscv_fsqrt
__riscv_float_abi_soft
__riscv_float_abi_single
__riscv_float_abi_double
__riscv_cmodel_medlow
__riscv_cmodel_medany
__riscv_cmodel_pic
__riscv_xlen
Reviewed by: ngie
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D11901
Create libdl.so.1 as a filter for libc.so.7 which exports public dl*
functions. The functions are resolved from the rtld instead, the goal
of creating library is to avoid errors from the static linker due to
missed libdl. For static binaries, an empty .o is compiled into
libdl.a so that static binaries still get dl stubs from libc.a.
Right now lld cannot create filter objects, disable libdl on arm64
when binutils are not used.
Reviewed by: bdrewery, dim (previos version); emaste
Exp run: PR 220525, done by antoine
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential revision: https://reviews.freebsd.org/D11504
Most important, use a correct signature for the
__pthread_cleanup_push_imp() stub, which was incorrectly generated
with two-args variant. The pthread_cleanup_info pointer was corrupted
in the forwarded call to the real libthr implementation, visible on
PowerPC and possibly ARM. [1]
Found and tested by: Mark Millard <markmi@dsl-only.net> [1]
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Make syslog(3) resilent to cancellation occuring in supported deferred
mode. Code must unlock syslog_mutex on cancel, install the cleanup
handler.
Diagnosed and tested by: eugen
Discussed with: dchagin
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
