`max-width: 100%` keeps images from expanding beyond
their container and creating horizontal overflow scroll
on small screens.
`height: auto` ensures the image scales proportionally
when width is adjusted.
asprintf is nice to use, but the _documented_ error return convention is
unclear:
> If memory allocation wasn't possible, or some other error occurs,
> these functions will return -1, and the contents of strp are undefined.
What exactly "undefined" means is up for debate: if it was really
undefined, the caller wouldn't be able to meaningfully clean up, because
they wouldn't know if strp is a valid pointer. So far we interpreted
"undefined" — in some parts of the code base — as "either NULL or a
valid pointer that needs to be freed", and — in other parts of the
codebase — as "always NULL". I checked glibc and musl, and they both
uncoditionally set the output pointer to NULL on failure.
There is also no information _why_ asprintf failed. It could be an
allocation error or format string error. But we just don't have this
information.
Let's add a wrapper that either returns a good string or a NULL pointer.
Since there's just one failure result, we don't need a separate return
value and an output argument and can simplify callers.
Whenever delegating UID ranges to a user namespace, it can also be
useful to map the foreign UID range, so that the container running in
the user namespace with delegated UID ranges can download container
images and unpack them to the foreign UID range.
Let's add an option mapForeign to make this possible. Note that this option
gives unprivileged users full access to the any foreign UID range owned directory
that they can access. Hence it is recommended (and already was recommended) to
store foreign UID range owned directories in a 0700 directory owned by the
owner of the tree to avoid access and modifications by other users.
This is already the case for the main users of the foreign UID range,
namely /var/lib/machines, /var/lib/portables and /home/<user> which all
use 0700 as their mode.
Users will also be able to create foreign UID range owned inodes in any
directories their own user can write to (on most systems this means /tmp,
/var/tmp and /home/<user>).
Motivation:
Currently, when setting the default boot pattern, boot assessment status
is not taken into account. This means that with boot assessment enabled,
when an explicit boot entry is configured as the default entry using an
EFI var, as is common for instance in A/B boot schemes, the configured
entry will be booted indefinitly, regardless of the entry's boot
assessment status.
In order to allow for this use case in combination with boot assessment,
we introduce a new `preferred` keyword, both in the config file and in the
bootctl CLI, that acts very similar to the existing `default` keyword but
takes boot assessment into account and never selects any entries that
have been marked as bad.
If the preferred pattern does not resolve to any bootable entry, and a
default pattern is also specified, then the default pattern will be
considered next, and we may then still select a known-bad entry to be
booted.
Fixes: https://github.com/systemd/systemd/issues/31215
Fixes: https://github.com/systemd/systemd/issues/40192
When sd_varlink_connect_url() gets an unknown URL we now
check if there is a `$LIBEXECDIR/varlink-bridges/$scheme`
binary and execute it (with the url as the first arguments).
This makes varlink more flexible as it provides a way to
dynamically add "bridges" in LIBEXECDIR/varlink-bridges/. This is
conceptually similar to the libvarlink `varlink --bridge` command
and allows to e.g. call varlink over http{,s} via e.g. the new
varlink-http-bridge.
With a running varlink-http-bridge [0] one can do:
```console
$ varlinkctl call http://localhost:8080/ws/sockets/io.systemd.Hostname \
io.systemd.Hostname.Describe {}
{
"Hostname" : "top",
...
```
Closes: https://github.com/systemd/systemd/issues/40640
[0] https://github.com/mvo5/varlink-http-bridge/pull/1
Unprivileged processes can send 768M in a FD-based message to journald,
which will be malloc'ed in one go, likely causing memory issues.
Set the limit for unprivileged users to 24M.
Allow coredumps as an exception, since we always allowed storing
up to the 768M max core files in the journal.
Reported on yeswehack.com as #YWH-PGM9780-48
Let's define a way how to mark codepaths that are subject to
deletion once the kernel baseline reaches a certain version, to make it
easier to find these cases.
WHile we are at it, introuce a whole section in CODING_STYLE about
kernel version compat.
I followed the new scheme in #39621, but we can merge the coding style
guidelines on this already.
This partially reverts commit e58ba80a40. Those
aliases were removed as part of the removal of sysvinit compat, but the removal
was immediately reported as a regression by users. In particular, users can
have one of those set as the default target, or use those names in Wants= or
Requires= dependencies. At least in Fedora, the removal was immediately
reverted.
When looking at our "portability and stability promise", I noticed that those
units are explicitly listed in the promise. Let's restore them upstream. They
are conditionalized under a new -Dcompat-sysv-interfaces=bool option, so that
downstreams like Arch that wasnt to strictly avoid legacy interfaces can easily
disable them. They are dropped from the docs, like we do for all deprecated
interfaces.
The kernel has a "don't break userspace" policy [1] which is very easy
to understand and like (even if the details are complicated). We had a
complicated policy statement, but the actual practice is that we'll
generally avoid changes that cause problems for users. So the whole
detailed table is more of a guideline than something that we can rely
on.
To improve public perception, and to align the docs with practice, let's
make a general promise to keep stability, and change the existing table
to a "guideline" that tells people which interfaces to use and which not
to use so that use and development of systemd don't conflict or create
pain.
The existing document was very long, and I think it'll have a bigger
impact if it shorter. In particular, the chart is dropped, because it
was of limited use and severly outdated, because we have added many new
interfaces and components without updating it. Adding the missing
elements (and then keeping it updated) would be a lot of effort. The
chart would be most useful to somebody trying to build a systemd
reimplementation, but there haven't been many attempts like this, so
let's save the work and drop it and make the document shorter.
I also dropped the mentions of Debian. Back in the day, we did indeed
adopt many Debian conventions for config files and such, but over the
years the scope of the project has grown quite a bit and that part
of systemd is a small fraction now. And we've adopted conventions
and ideas from many other places too, so we don't mention Debian
specifically.
[1] https://docs.kernel.org/admin-guide/reporting-regressions.html
I had to sketch this out before I could get the internals of
systemd-sysupdate straight in my head, particularly around how an
`UpdateSet` points to one `Instance` from each of a set of `Resource`s,
and those `Instance`s are either all sources or all targets.
Hopefully this is useful to the next person to look at the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This does not yet support directory images properly
as systemd itself does not support unpriv directory
images properly yet.
The user profiles are a copy of the system profiles but without
DynamicUser=yes (can't be used by user managers) and without
ProtectHome=yes (this masks /home which breaks StateDirectory= which
is lcoated inside /home)
When setting SYSTEMD_LOG_LEVEL=debug and debugging a tool that happens
to do NSS lookups, the resulting logs from varlink are obnoxiously
verbose. Let's parse a separate log level environment variable in NSS
to allow overriding the log level for NSS specifically so these noisy
logs can be silenced.
In order to make "freeze" attacks against the update logic harder let's
add the ability to encode a "Best Before" date into SHA256SUMS directory
listings: if the current time is already beyond that time, we'll ignore
the SHA256SUMS as "stale" and fail the upgrade. Or in other words: the
freeze attack will now result in a client-side error eventually, instead
of success state.
The best before data is encoded in an optional pseudo-file listed in SHA256SUMS:
any file named BEST-BEFORE-YYYY-MM-DD.
As announced by a few releases now, finally drop support for
sysvinit scripts.
Keep rc-local generator for now, as it's really a distinct
feature even though from the same era.
We said in the header that "all EFI variables use the vendor UUID
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f", but people not familiar with
UEFI might not know that this is concatenated with the variable name.
Let's use the full form once — when introducing the variable — to
make it easier to grep and search for.
While at it, use sembreaks in the document. This makes subsequent
changes much easier to review. (It also shows that some sentences
are rather long and thus hard to understand.)
davidak
Rito Rhymes
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Daan De Meyer
r-vdp
Yu Watanabe
andre4ik3
Michael Vogt
Tabis Kabis
Luca Boccassi
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Philip Withnall
Lennart Poettering
Ben Boeckel
Luca Boccassi