Of course, alloca() shouldn't be used with anything that can grow
without bounds anyway, but let's better safe than sorry, and catch this
early.
Since alloca() is not supposed to return an error we trigger an
assert() instead, which is still better than heap trickery.
Previously we were a bit sloppy with the index and size types of arrays,
we'd regularly use unsigned. While I don't think this ever resulted in
real issues I think we should be more careful there and follow a
stricter regime: unless there's a strong reason not to use size_t for
array sizes and indexes, size_t it should be. Any allocations we do
ultimately will use size_t anyway, and converting forth and back between
unsigned and size_t will always be a source of problems.
Note that on 32bit machines "unsigned" and "size_t" are equivalent, and
on 64bit machines our arrays shouldn't grow that large anyway, and if
they do we have a problem, however that kind of overly large allocation
we have protections for usually, but for overflows we do not have that
so much, hence let's add it.
So yeah, it's a story of the current code being already "good enough",
but I think some extra type hygiene is better.
This patch tries to be comprehensive, but it probably isn't and I missed
a few cases. But I guess we can cover that later as we notice it. Among
smaller fixes, this changes:
1. strv_length()' return type becomes size_t
2. the unit file changes array size becomes size_t
3. DNS answer and query array sizes become size_t
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76745
Rather than choosing to set or unset any of these flag
use kernel defaults. This patch makes following properties to unset.
UseBPDU = unset
HairPin = unset
FastLeave = unset
AllowPortToBeRoot = unset
UnicastFlood = unset
If an interface name is changed, then the link state, especially
managed or not, may need to be updated, as its corresponding
.link or .network files may be different. So, let's once drop
the link and recreate a new link object.
Fixes#8794.
Based on information provided by phenest in
https://github.com/systemd/systemd/issues/5341.
Those keys map to some special functions in windows, so let's map them
to prog1/prog2 so the user map them to something.
Fixes#5341.
This cleans up handling of MTU values across the codebase. Previously
MTU values where stored sometimes in uint32_t, sometimes in uint16_t,
sometimes unsigned and sometimes in size_t. This now unifies this to
uint32_t across the codebase, as that's what netlink spits out, and what
the majority was already using.
Also, all MTU parameters are now parsed with config_parse_mtu() and
config_parse_ipv6_mtu() is dropped as it is now unneeded.
(Note there is one exception for the MTU typing: in the DCHPv4 code we
continue to process the MTU as uint16_t value, as it is encoded like
that in the protocol, and it's probably better stay close to the
protocol there.)
It's mostly a wrapper around parse_mtu() but with some nicer logging.
The address family is initialized from the "ltype" parameter, so that
configuration file parser tables can be easily declare it.
We use MTUs all over the place, let's add a unified, strict parser for
it, that takes MTU ranges into account.
We already have parse_ifindex() close-by, hence this appears to be a
natural addition, in particular as the range checking is not entirely
trivial to do, as it depends on the protocol used.
If enabling controller for some reason fails we need to clear error
for the FILE stream. Enabling remaining controllers would otherwise
fail because write_string_stream_ts() checks for ferror(f) and returns
-EIO if there is one.
Broken by commit <77fa610b22>.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This fixes the following warning with clang and meson-0.46.0,
```
WARNING: Passed invalid keyword argument "name".
WARNING: This will become a hard error in the future.
WARNING: Passed invalid keyword argument "name".
WARNING: This will become a hard error in the future.
Compiler for C supports arguments -Wno-typedef-redefinition: YES
WARNING: Passed invalid keyword argument "name".
WARNING: This will become a hard error in the future.
WARNING: Passed invalid keyword argument "name".
WARNING: This will become a hard error in the future.
Compiler for C supports arguments -Wno-gnu-variable-sized-type-not-at-end: YES
```
In particular, this confirms that the Found state needs to remain a bit-field:
$ systemd-analyze dump |grep 'Found: '|sort |uniq -c
105 Found: found-udev
3 Found: found-udev,found-mount
1 Found: found-udev,found-swap
Unfortunately this needs a new binary to do the mount because there's just
too many special steps to outsource this to systemd-mount:
- EPERM needs to be treated specially
- UserRuntimeDir= setting must be obeyed
- SELinux label must be adjusted
This allows user@.service to be started independently of logind.
So 'systemctl start user@nnn' will start the user manager for user nnn.
Logind will start it too when the user logs in, and will stop it (unless
lingering is enabled) when the user logs out.
Fixes#7339.
This removes the UserTasksMax= setting in logind.conf. Instead, the generic
TasksMax= setting on the slice should be used. Instead of a transient unit we
use a drop-in to tweak the default definition of a .slice. It's better to use
the normal unit mechanisms instead of creating units on the fly. This will also
make it easier to start user@.service independently of logind, or set
additional settings like MemoryMax= for user slices.
The setting in logind is removed, because otherwise we would have two sources
of "truth": the slice on disk and the logind config. Instead of trying to
coordinate those two sources of configuration (and maintainer overrides to
both), let's just convert to the new one fully.
Right now now automatic transition mechanism is provided. logind will emit a
hint when it encounters the setting, but otherwise it will be ignored.
Fixes#2556.
(or in terms of the names of the actual files on disk, do not link
libsystemd-shared-238.a into libcore.a).
libsystemd_static is linked into libsystemd_shared, which in turn means that
anything that links to libcore and libsystemd_shared will get libsystemd_static
twice:
$ cc -o systemd 'systemd@exe/src_core_main.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie -DVALGRIND -Wl,--start-group src/core/libcore.a src/shared/libsystemd-shared-238.a src/shared/libsystemd-shared-238.so -pthread -lrt -lseccomp -lselinux -lmount -lblkid -Wl,--end-group -lseccomp -lpam -L/lib64 -laudit -lkmod -lmount -lrt -lcap -lacl -lcryptsetup -lgcrypt -lip4tc -lip6tc -lseccomp -lselinux -lidn -llzma -llz4 -lblkid '-Wl,-rpath,$ORIGIN/src/shared' -Wl,-rpath-link,/home/zbyszek/src/systemd/build/src/shared
This propagation of the dependency seems correct (in the sense that meson is
doing the expected thing based on the given configuration). Linking was done
this way in the original meson conversion. I was probably trying to get
everything to compile and link, I'm not sure why this particular choice was
made. In the meantime, meson has gotten better at propagating dependencies, so
it's possible that this had slightly different effect in the original
conversion, but I did not verify this. Either way, I think we should drop this.
With the patch:
$ cc -o systemd 'systemd@exe/src_core_main.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie -DVALGRIND -Wl,--start-group src/core/libcore.a src/shared/libsystemd-shared-238.so -pthread -lrt -lseccomp -lselinux -lmount -Wl,--end-group -lblkid -lrt -lseccomp -lpam -L/lib64 -laudit -lkmod -lselinux -lmount '-Wl,-rpath,$ORIGIN/src/shared' -Wl,-rpath-link,/home/zbyszek/src/systemd/build/src/shared
This is more correct because we're not linking the same code twice.
With the patch, libystemd_static is used in exactly four places:
- src/shared/libsystemd-shared-238.so
- src/udev/libudev.so.1.6.10
- pam_systemd.so
- test-bus-error
(compared to a bunch more executables before, including systemd,
systemd-analyze, test-hostname, test-ns, etc.)
Size savings are also noticable:
$ size /var/tmp/inst?/usr/lib/systemd/libsystemd-shared-238.so
text data bss dec hex filename
2397826 578488 15920 2992234 2da86a /var/tmp/inst1/usr/lib/systemd/libsystemd-shared-238.so
2397826 578488 15920 2992234 2da86a /var/tmp/inst2/usr/lib/systemd/libsystemd-shared-238.so
$ size /var/tmp/inst?/usr/lib/systemd/systemd
text data bss dec hex filename
1858790 261688 9320 2129798 207f86 /var/tmp/inst1/usr/lib/systemd/systemd
1556358 258704 8072 1823134 1bd19e /var/tmp/inst2/usr/lib/systemd/systemd
$ du -s /var/tmp/inst?
52216 /var/tmp/inst1
50844 /var/tmp/inst2
https://github.com/google/oss-fuzz/issues/1330#issuecomment-384054530 might be related.
This drops a good number of type-specific _cleanup_ macros, and patches
all users to just use the generic ones.
In most recent code we abstained from defining type-specific macros, and
this basically removes all those added already, with the exception of
the really low-level ones.
Having explicit macros for this is not too useful, as the expression
without the extra macro is generally just 2ch wider. We should generally
emphesize generic code, unless there are really good reasons for
specific code, hence let's follow this in this case too.
Note that _cleanup_free_ and similar really low-level, libc'ish, Linux
API'ish macros continue to be defined, only the really high-level OO
ones are dropped. From now on this should really be the rule: for really
low-level stuff, such as memory allocation, fd handling and so one, go
ahead and define explicit per-type macros, but for high-level, specific
program code, just use the generic _cleanup_() macro directly, in order
to keep things simple and as readable as possible for the uninitiated.
Note that before this patch some of the APIs (notable libudev ones) were
already used with the high-level macros at some places and with the
generic _cleanup_ macro at others. With this patch we hence unify on the
latter.
Right now gpt-auto-generator will iterate through all mount entries, and
silently ignore failure to check if the mount point target is empty.
This can hide real errors (in particular from MAC), so instead let's warn
and return failure at the end if this happens. We will still iterate
over other candidates, so there should be no change in behaviour.
Logging is moved into path_is_busy() to avoid the duplication of the same
logging code in the two callers.
A regression was introduced that caused the mtime of /etc/.updated
and /var/.updated to be the current time when systemd-update-done
ran instead of being copied from /usr.
This was nearly fixed, but due to fflush being called after mtime
was carefully set, it was overwritten with the current time.
Regression introduced in 872c403963
A fix was just missed in 39c38d773fFixes#8806
With the recent terminal_urlify() APIs we'll now sometimes generate
clickable link CSO sequences. Hence we should also be able to remove
them again from strings. This beefs up the logic to do so.
Follow-up for: 23b27b39d2
Quoting https://github.com/systemd/systemd/pull/8760#discussion_r183321060:
> When we originally added the errno patching we went for a "best of both
> worlds" approach, i.e. that we override errno if an error is specified, but
> if no error is specified (i.e. 0 is passed as error code) then we use the
> previously set errno, similar in style how plain `printf()` would do it. In
> retrospect I think we almost never purposefully made use of the second,
> i.e. the plain `printf()` logic, but we multiple times ran into this case
> accidentally and introduced a bug. Hence yes, it probably makes sense to
> switch this over, and consistently ignore the `errno` already set and always
> override it with the error passed in. The only problem I see with that is: I
> wonder if there might be a case or two lurking somewhere where we actually
> made use of the "best of both worlds" approach, and if so, if we can detect
> where... (But then again, even if there is, and we fail to find those cases,
> maybe that's not all bad, as it's just a few new bugs against probably fixing
> many more old and future bugs, if you follow what I mean).
I scanned our codebase, and found some bugs in the value passed to log_*_errno,
but no intentional cases of error=0 being passed.
I'm not sure if I understand the original code. AFAICS, errno does not
have to be set at all in this callback.
ratelimit_test() returns positive if we are under limit. The code would only
log if the condition happened very often, which I assume is not inteded, and
this check was supposed to prevent too much logging.
