Some filesystem magics are too big to fit in 31 bits,
and are wrapped to negative. f_type is an int on 32 bits, so
it is signed, and we get a warning on comparison.
The behaviour of the common name##_from_string conversion is surprising.
It accepts not only the strings from name##_table but also any number
that falls within the range of the table. The order of items in most of
our tables is an internal affair. It should not be visible to the user.
I know of a case where the surprising numeric conversion leads to a crash.
We will allow the direct numeric conversion only for the tables where the
mapping of strings to numeric values has an external meaning. This holds
for the following lookup tables:
- netlink_family, ioprio_class, ip_tos, sched_policy - their numeric
values are stable as they are defined by the Linux kernel interface.
- log_level, log_facility_unshifted - the well-known syslog interface.
We allow the user to use numeric values whose string names systemd does
not know. For instance, the user may want to test a new kernel featuring
a scheduling policy that did not exist when his systemd version was
released. A slightly unpleasant effect of this is that the
name##_to_string conversion cannot return pointers to constant strings
anymore. The strings have to be allocated on demand and freed by the
caller.
strtol() and friends may set EINVAL if no conversion was performed, but
they are not required to do so. In practice they don't. We need to check
for it.
https://bugzilla.redhat.com/show_bug.cgi?id=870577
commit 49371bb fixed the observed division by zero, but missed another
occurrence of the same bug. It was also not the optimal fix. We can
simply make the divisor a constant by swapping it with the compared
value.
In early userspace, if kernel initialization happens extremely quickly,
a call to systemd-timestamp can potentially result in division by zero.
Ensure that the check in timespec_load, which only makes sense if tv_sec
is greater than zero, is guarded by this condition.
Much like logind has a client in loginctl, and journald in journalctl
introduce timedatectl, to change the system time (incl. RTC), timezones
and related settings.
Among other cleanups this introduces a threshold for the size of binary
blobs we serialize as integer arrays in the JSON output. THis can be
disabled via --all.
This requires a little bit of tip-toeing around to explicitly avoid
touching the environment from a sig handler. Instead, simply create a
function to reset the var to its "unset" state, allowing the next call
to columns() to recalculate and cache the new value.
In many cases this might have a negative effect since we drop escaping
from strings where we better shouldn't have dropped it.
If unescaping makes sense for some settings we can readd it later again,
on a per-case basis.
https://bugs.freedesktop.org/show_bug.cgi?id=54522
- Make writing/reading of /etc/timezone dependendent of HAVE_SYSV_COMPAT
- Introduce symlink_atomic() after all, and use it
- Use relative symlink for /etc/localtime
Call rm_rf_children_dangerous() recursively rather than falling back to
rm_rf_children(). This fixes a bug in systemd-tmpfiles.
The problem can easily be reproduced by:
# mount /dev/sda1 /mnt
# mkdir /mnt/test
# echo "D /mnt" > /root/test.conf
# systemd-tmpfiles --remove /root/test.conf
Attempted to remove disk file system, and we can't allow that.
rm_rf(/root/test): Operation not permitted
Reported-by: Lukas Jirkovsky <l.jirkovsky@gmail.com>
Lennart Poettering