It seems that there are still some applications that use ftime(3)
(for example, science/siconos and sysutils/lcdproc). The issue
is that we don't build libcompat as a shared library anymore.
The easiest solution is to move it to libutil, until we
deprecate it for good.
This solution was proposed by kib@ in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257789.
PR: 257789
MFC after: 1 month
Reviewed by: kib (ages ago)
Differential Revision: https://reviews.freebsd.org/D39994
(cherry picked from commit bb421be6c1174fad837973acc5e4a7bade4489db)
This is an implementation detail which is likely to become irrelevant in
the future, as we move to not resetting the priority if the
corresponding capability is not present in the configuration file
('/etc/login.conf').
GitHub's code search and Google show no use of this public constant, and
it doesn't exist in OpenBSD and NetBSD.
So, remove this definition and its sole use in-tree.
PR: 276570 (exp-run)
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43609
(cherry picked from commit c7e645269f1c7e9872a7ccf6b72f045c55a66793)
Approved by: markj (mentor)
This public constant has not been used in-tree since 1997 (this was
noticed while working on previous commit "setusercontext(): umask: Set
it only once (in the common case)").
Since it was an implementation detail and GitHub's code search and
Google show no use of this symbol today, simply remove it.
PR: 276570 (exp-run)
Reviewed by: emaste, kib (earlier version, then part of D40344)
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43608
(cherry picked from commit e3a396eb2a029e5dc9161469735aa3f7f16845d1)
Approved by: markj (mentor)
Setting the process priority is done only when the current process'
effective UID corresponds to that for which context is to be set.
Consequently, setting priority is done with appropriate credentials and
will fail if the target user tries to raise it unduly via his
'~/.login_conf'.
PR: 271751
Reviewed by: kib, Andrew Gierth <andrew_tao173.riddles.org.uk>
Approved by: emaste (mentor)
MFC after: 3 days
Relnotes: yes
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40352
(cherry picked from commit f2a0277d3e51a6a839151eef17f466d0db2b7300)
Approved by: markj (mentor)
In preparation for setting priorities from '~/.login_conf' and to ease
reading of setusercontext().
No functional change.
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40350
(cherry picked from commit 7b94ec550ef6e7b75d608e125e9b78478197d4e7)
Approved by: markj (mentor)
Priority is reset to 0 if not explicitly specified.
While here, be more explicit about what "Initial priority (nice) level"
means and document that it is possible to set real-time or idle class'
priorities with this capability.
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40689
(cherry picked from commit aa96945e71b0f724e6ce673194d23f58d2d637d3)
Approved by: markj (mentor)
Polish the syslog messages to contain readily useful information.
Behavior of capability 'priority' is inconsistent with what is done for
all other contexts: 'umask', 'cpumask', resource limits, etc., where an
absence of capability means to inherit the value. It is currently
preserved for compatibility, but is subject to change on a future major
release.
Reviewed by: emaste, kib (older version)
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40349
(cherry picked from commit d988621b0c25209866ed5a98b1a8b20269935761)
Approved by: markj (mentor)
Column "Notes" in fact only contains default values for capabilities, so
make this clear by renaming it to "Default".
Add a small introductory text mentioning it, and what an absence of
default value means (inheritance).
PR: 271748
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40347
(cherry picked from commit 92b2c4358f57ef84f161efd8370ba4832bd9261a)
Approved by: markj (mentor)
Remove indentation by inverting the big 'if (lc)' and using 'return'.
Use explicit binary operators to produce booleans.
Reviewed by: emaste, kib, dchagin
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40346
(cherry picked from commit 771d5c93ab5a3fb1701d9706df2ce87d6a9da6f3)
Approved by: markj (mentor)
'inherit' explicitly indicates that the umask should not be changed.
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Relnotes: yes
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40687
(cherry picked from commit c328e6c6ccaa4cdf921c16d68a2f2c5992dd3b72)
Approved by: markj (mentor)
The umask is simply left unchanged if no explicit value is specified in
the login class capabilities database.
PR: 271747
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40345
(cherry picked from commit 0d1fe948d97d2d6e3708349b74cf438f9604a8d1)
Approved by: markj (mentor)
Simplify the code and make it more coherent (umask was the only context
setting not modified by setlogincontext() directly).
Preserve the current behavior of not changing the umask if none is
specified in the login class capabilities database, but without the
superfluous umask() dance. (The only exception to this is that
a special value no user is likely to input in the database now stands
for no specification.)
If some user has a 'umask' override in its '~/.login_conf', the umask
will still be set twice as before (as is the case for all other context
settings overriden in '~/.login_conf').
Log a warning in case of an invalid umask specification.
This change makes it apparent that the value of LOGIN_DEFUMASK doesn't
matter. It will be removed in a subsequent commit.
PR: 271747
Reviewed by: emaste, kib (earlier version)
Approved by: emaste
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40344
(cherry picked from commit e99c28e93bd4d04ff877459734e9ce06ad2335a7)
Approved by: markj (mentor)
Commit 35305a8dc1 (r211393) added a check on whether 'uid' was equal
to getuid() before calling setlogincontext(). Doing so still allows
a setuid program to apply resource limits and priorities specified in
a user-controlled configuration file ('~/.login_conf') where
a non-setuid program could not. Plug the hole by checking instead that
the process' effective UID is the target one (which is likely what was
meant in the initial commit).
PR: 271750
Reviewed by: kib, des
MFC after: 2 weeks
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40351
(cherry picked from commit 892654fe9b5a9115815c30a423b8db47185aebbd)
The login.conf's "priority" capability allows to set priorities in the
idle or realtime classes in addition to the classical nice values (-20
to 20), through a natural extension where values greater than 20 put the
processes in the idle class (with priority adjusted within RTP_PRIO_MIN
and RTP_PRIO_MAX, 21 being converted to 0, 22 to 1, etc.) and values
lower than -20 put the process in the realtime class (with priority
adjusted within RTP_PRIO_MIN and RTP_PRIO_MAX, -21 being converted to
RTP_PRIO_MAX (31), -22 to 30, etc.).
Before this fix, in the latter case (realtime class), -21 was converted
to 30, and RTP_PRIO_MAX (31) could never be specified.
While here, change the priority computation for the idle-class case to
be symmetrical and use RTP_PRIO_MIN (in practice, this changes nothing
at all, since RTP_PRIO_MIN is 0; but this is the correct theoretical
formula, which would work as well with other values of RTP_PRIO_MIN).
PR: 271727
Reviewed by: imp, kib
MFC after: 2 weeks
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40339
(cherry picked from commit bd572be78436473a2ad4c1b78728b739c74ef238)
Modified functions: login_getcaptime(), login_getcapnum(),
login_getcapsize().
They all call cgetstr(), which returns -2 on such conditions and already
sets errno to ENOMEM, arguably the appropriate value for these functions
as well.
No in-tree consumer currently checks for errno on error reported by
these functions, so this change has no other code impact.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40342
(cherry picked from commit b8c1aadef9d80786daf731300c33d3a001261422)
We include paths.h in getlocalbase.c, which defines _PATH_LOCALBASE.
This will override a definition on the command line, meaning it is
impossible to override like how the manpage says you can, and it means
the code to provide a fallback default is dead as the macro is always
defined.
Instead, introduce a new LOCALBASE_PATH macro like LOCALBASE_CTL_LEN
that can be set on the command line and will default to the system's
existing _PATH_LOCALBASE to avoid duplicating the default here.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D40975
As of f32db40650 quotes may be used to specify login class
capabilities that include commas. This is true in general but is
particularly relevant for setenv, a comma-separated list of environment
variables and values, so mention it there.
PR: 236204
Sponsored by: The FreeBSD Foundation
The current code silently ignores characters after the unit as long
the unit themselves were recognized. This commit makes expand_number(3)
to fail with EINVAL if buf did not terminate after the unit character.
Historically, the function accepts and ignores "B" as a SI unit, this
behavior is preserved and e.g. KB, MB are still accepted as aliases of
K and M, document this behavior in the manual page.
While I am there, also write a few test cases to validate the behavior.
Reviewed-by: emaste
MFC-after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D40482
In order to allow to add cpuset(2) functionality to more utilities than just
cpuset(1) move the parselist code into libutil
While here, make the code a little more "library" friendly, by returning a range
of various errors so that the consumer can check for them and report appropriate
error message to the users
(One of the planed usage is the jail(8) utility)
Reviewed by: jilles
Differential Revision: https://reviews.freebsd.org/D12873
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
- missing comma before name
- possible typo in section name: Sh CAVEAT instead of CAVEATS
- useless macro: Tn
- blank line in fill mode, using .sp
- no blank before trailing delimiter: Dv NULL?
MFC after: 3 days
Previously we invoked the sysctl with a NULL buffer to query the size,
allocated a buffer, then invoked it again to fetch the data.
As we only handle the case where the sysctl provides data of the
expected size we can just allocate a correctly-sized buffer to begin
with.
Reported by: Thomas Hurst via Twitter
Reviewed by: kevans
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35140
which is the wrapper around the vm.swap_objects sysctl, same as
kinfo_getvmobject(3) wraps vm.objects.
Submitted by: Yoshihiro Ota
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D29754
login.conf.5 listed passwordtime in RESERVED CAPABILITIES, which is a
section for capabilities not implemented in the base system. However,
passwordtime has been implemented in the base for several years now.
PR: 246099
Reported by: avg
Reviewed by: 0mp
MFC after: 3 days
Trim leading spaces in variable names when the list is e.g.
pretty-formatted in /etc/login.conf or ~/.login_conf.
PR: 247947
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D25649
After the commit of the current version, Scott Long pointed out, that an
attacker might be able to cause a use-after-free access if this function
returned the value of the sysctl variable "user.localbase" by freeing
the allocated memory without the cached address being cleared in the
library function.
To resolve this issue, I have proposed the originally suggested version
with a statically allocated buffer in a review (D27370). There was no
feedback on this review and after waiting for more than 2 weeks, the
potential security issue is fixed by this commit. (There was no security
risk in practice, since none of the programs converted to use this
function attempted to free the buffer. The address could only have
pointed into the heap if user.localbase was set to a non-default value,
into r/o data or the environment, else.)
This version uses a static buffer of size LOCALBASE_CTL_LEN, which
defaults to MAXPATHLEN. This does not increase the memory footprint
of the library at this time, since its data segment grows from less
than 7 KB to less than 8 KB, i.e. it will get two 4 KB pages on typical
architectures, anyway.
Compiling with LOCALBASE_CTL_LEN defined as 0 will remove the code
that accesses the sysctl variable, values between 1 and MAXPATHLEN-1
will limit the maximum size of the prefix. When built with such a
value and if too large a value has been configured in user.localbase,
the value defined as ILLEGAL_PREFIX will be returned to cause any
file operations on that result to fail. (Default value is "/dev/null/",
the review contained "/\177", but I assume that "/dev/null" exists and
can not be accessed as a directory. Any other string that can be assumed
not be a valid path prefix could be used.)
I do suggest to use LOCALBASE_CTL_LEN to size the in-kernel buffer for
the user.localbase variable, too. Doing this would guarantee that the
result always fit into the buffer in this library function (unless run
on a kernel built with a different buffer size.)
The function always returns a valid string, and only in case it is built
with a small static buffer and run on a system with too large a value in
user.localbase, the ILLEGAL_PREFIX will be returned, effectively causing
the created path to be non-existent.
Differential Revision: https://reviews.freebsd.org/D27370
