virtual_oss(8): Create loopback devices with GID_AUDIO
Make sure the user is part of the audio group to avoid unintended
snooping of loopback audio by unprivileged users.
While here, retire voss_dsp_perm, since we don't use the same value
everywhere now.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: emaste
Pull-Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/26
(cherry picked from commit 5f904cb1b05c94453727abb606d6109fe504b10b)
rc: virtual_oss: Create a loopback device in the default configuration
The loopback device allows us to record desktop sound by reading from
it, or even use it as an input device, for example during a call.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: emaste
Pull-Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/16
(cherry picked from commit 8532b4a436364d04d5c1feb7af5ecd4b5df71a9f)
lpd: Avoid buffer overflow when sending a job
When forwarding a print job to a remote server, we could overflow the
command buffer if a control or data file had a very long name.
MFC after: 1 week
Reported by: Joshua Rogers <joshua at joshua.hu>
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57184
(cherry picked from commit f2c7c5f94803b67a9a6af625d4fc8882d2afda6c)
lpd: Restore ability to specify a port number
This has been broken since IPv6 support was added in 2000. We would
validate the port number (which had to be a port number, but can now
also be a service name) and then ignore it.
MFC after: 1 week
Fixes: 08829865f659 ("IPv6 support for lpr.")
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57181
(cherry picked from commit c0cae7d8da50daa87af4cd6d7c9a2043343b506f)
lpr: Add deprecation notice
These programs require elevated privileges to work and have not seen
regular maintenance in decades. Unless someone steps up and overhauls
them, we will have to remove them before 16.0. Better-maintained
alternatives are available in ports (print/cups, sysutils/LPRng).
MFC after: 3 days
(cherry picked from commit d57dee7ab66f60537b557cb602be194e3eed253d)
lpd: Avoid buffer overflow when sending a job
When forwarding a print job to a remote server, we could overflow the
command buffer if a control or data file had a very long name.
MFC after: 1 week
Reported by: Joshua Rogers <joshua at joshua.hu>
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57184
(cherry picked from commit f2c7c5f94803b67a9a6af625d4fc8882d2afda6c)
lpd: Restore ability to specify a port number
This has been broken since IPv6 support was added in 2000. We would
validate the port number (which had to be a port number, but can now
also be a service name) and then ignore it.
MFC after: 1 week
Fixes: 08829865f659 ("IPv6 support for lpr.")
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57181
(cherry picked from commit c0cae7d8da50daa87af4cd6d7c9a2043343b506f)
ttymsg: Overhaul
* Instead of an error string, return the usual 0 or -1 and let the caller
figure out what, if anything, to tell the user.
* Avoid string manipulations by opening /dev first and using openat()
with O_RESOLVE_BENEATH.
* Add a boolean argument which, if false, causes ttymsg() to return
without sending the message if the tty's group-writable bit is not
set. This saves programs that respect this setting (like syslogd(8))
from having to check before calling ttymsg().
* Update all callers.
The observable effect of this change is minimal except for slightly
different error messages when ttymsg() fails. However, syslogd(8) will
no longer print spurious error messages on the console after trying and
failing to write a log message to an X11 session.
[7 lines not shown]
ttymsg: Overhaul
* Instead of an error string, return the usual 0 or -1 and let the caller
figure out what, if anything, to tell the user.
* Avoid string manipulations by opening /dev first and using openat()
with O_RESOLVE_BENEATH.
* Add a boolean argument which, if false, causes ttymsg() to return
without sending the message if the tty's group-writable bit is not
set. This saves programs that respect this setting (like syslogd(8))
from having to check before calling ttymsg().
* Update all callers.
The observable effect of this change is minimal except for slightly
different error messages when ttymsg() fails. However, syslogd(8) will
no longer print spurious error messages on the console after trying and
failing to write a log message to an X11 session.
[7 lines not shown]
inpcb: a pcb may travel only from the wild hash to exact, not vice versa
The only possible way to exercise in_pcbrehash() is to bind(2) and then
connect(2). The second branch was a dead code since fdb987bebddf.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57241
nfsd: Allow vfs.nfsd.srvmaxio to be up to 4Mbytes
Without this patch, the maximum setting for
vfs.nfsd.srvmaxio was 1Mbyte. This patch increases
that to 4Mbytes.
The same as for any setting above 128Kbytes, settings up to
4Mbytes require that kern.ipc.maxsockbuf be increased.
(A message generated after setting vfs.nfsd.srvmaxio via
the /etc/rc.conf variable nfs_server_maxio will indicate
the minimum setting, which will be somewhat greater than
four times the setting of vfs.nfsd.srvmaxio.)
(cherry picked from commit b92b9da3300655c86dcd42ea8a5ba45badd90847)
subr_uio.c: Remove a KASSERT() for large NFS server I/O
When the NFS server is set to allow an I/O size greater
than 1Mbyte (not allowed in FreeBSD's main yet), a
KASSERT() in allocuio() can fail when:
zfs_freebsd_write()->zfs_write()->zfs_uiocopy()
->cloneuio()->allocuio()
is called for a large NFS server write.
Since the userland API callers to allocuio() already
check that the size does not exceed UIO_MAXIOV,
there does not seem to be a need to a KASSERT()
here.
Removing the KASSERT() allows NFS server writes
of greater than 1Mbyte to work, once the NFS code
is patched to allow them.
(cherry picked from commit 13d3bd165e225eec9af91b6e3361c2482931f95b)
install: Bump compare size limit (128MB) to support large binaries
Preserve metadata and prevent redundant disk writes during builds with
the install's -C (compare) flag.
The previous historical comparison limit of 16MB is insufficient for
modern toolchains, frequently choked or bypassed by a large base
components like LLVM/Clang, kernels, Rust apps, and large runtime
libraries.
By leaving matching files alone, install keeps their modification timestamps
intact. make(1) safely ignores those files on subsequent runs.
Base examples: 15.0 amd64 GENERIC kernel - 28MB, clang - 105MB, lldb - 97MB, etc.
Reviewed by: glebius
Approved by: glebius (mentor)
Obtained from: Fudo Security
MFC after: 2 weeks
[2 lines not shown]
syslogd: Fix ereregex property filters and add test
This change fixes Bug 293879, where ereregex filters in syslogd
did not handle alternation correctly.
The issue appears to come from mixing up two different kinds of
flags: syslogd's internal serialized filter flags in
usr.sbin/syslogd/syslogd.h, and the regex compilation flags from
include/regex.h. ereregex was storing REG_EXTENDED in cmp_flags,
even though cmp_flags is meant to carry syslogd's own FILT_FLAG_*
values for configuration serialization and reconstruction.
REG_EXTENDED has the same bit value as FILT_FLAG_EXCLUDE, so the
filter could be reconstructed with the wrong semantics.
The fix stores FILT_FLAG_EXTENDED instead, allowing syslogd to
correctly REG_EXTENDED when compiling the regex.
A test was also added for both ereregex and !ereregex filters.
[8 lines not shown]
netmap: silence -Wdefault-const-init-field-unsafe warning
The netmap_ring struct starts with various const members and rencent
clang warns about leaving them uninitialized. Having them const in the
first place is highly suspicious since they are updated with various
macros but using hand-coded __DECONST(). But fixing that is a more
invasive change that I am unable to test.
```
.../freebsd/sys/dev/netmap/netmap_kloop.c:320:21: error: default initialization of an object of type 'struct netmap_ring' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
320 | struct netmap_ring shadow_ring; /* shadow copy of the netmap_ring */
| ^
.../freebsd/sys/net/netmap.h:290:16: note: member 'buf_ofs' declared 'const' here
290 | const int64_t buf_ofs;
| ^
```
Test Plan: Compiles
[5 lines not shown]
if_ovpn.c: fix use of uninitialized variable
In case we use OVPN_CIPHER_ALG_NONE, the memcpy will attempt to copy 0
bytes from an uninitialized pointer. While the memcpy() implementation
will treat this as a no-op and not actually dereferece the undefined
variable it is still undefined behaviour to the compiler and should be
fixed. Found by building with clang HEAD
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D52543
(cherry picked from commit 969be39fb3caf4272f128dbf3267ceba5966a6ce)
netmap: silence -Wdefault-const-init-field-unsafe warning
The netmap_ring struct starts with various const members and rencent
clang warns about leaving them uninitialized. Having them const in the
first place is highly suspicious since they are updated with various
macros but using hand-coded __DECONST(). But fixing that is a more
invasive change that I am unable to test.
```
.../freebsd/sys/dev/netmap/netmap_kloop.c:320:21: error: default initialization of an object of type 'struct netmap_ring' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
320 | struct netmap_ring shadow_ring; /* shadow copy of the netmap_ring */
| ^
.../freebsd/sys/net/netmap.h:290:16: note: member 'buf_ofs' declared 'const' here
290 | const int64_t buf_ofs;
| ^
```
Test Plan: Compiles
[5 lines not shown]
