Based on https://github.com/systemd/systemd/issues/7820, this adds support for
quota enforcement to State, Cache, and Log exec directories.
* Add new directives, StateDirectoryQuota=, CacheDirectoryQuota=, and
LogDirectoryQuota=, to define quotas as percentages (hard limits for
blocks and inodes) or absolute values (hard limits for blocks only).
* Add new directives, StateDirectoryQuotaAccounting=,
CacheDirectoryQuotaAccounting= and LogDirectoryQuotaAccounting= to keep
track of storage quotas but not enforce them (effectively just assigning
a project ID to defined exec directories).
Example:
```
StateDirectory=quotadir
StateDirectoryQuota=1%
Jan 06 22:55:46 abeltran: Storage quotas set for /var/lib/private/quotadir. Block limit = 2639404, inode limit = 671088
root@abeltran:/var/lib/private# lsattr -pR
3153000189 --------------e----P-- ./quotadir
root@abeltran:/var/lib/private# repquota -P /datadrive
*** Report for project quotas on device /dev/sdc1
Block grace time: 7days; Inode grace time: 7days
Block limits File limits
Project used soft hard grace used soft hard grace
----------------------------------------------------------------------
#0 -- 213200 0 0 4086 0 0
#3153000189 -- 2639404 0 2639404 2 0 671088
```
This was all very confusing and not matching our coding style
recommendations. Let's fix that.
Prompted by #37897, which really should make use of BootEntryType, but
we better clean it up first.
So we exposed different names for the entry types in JSON than we named
our enum values. Which is very confusing. Let's unify that. Given that
the JSON fields are externally visible let's stick to that naming, even
though I think "unified" and "conf" would have been more descriptive.
This ensures we follow our usual logic that the enum identifiers and the
strings they map to use the same naming.
This helper does not translate BootEntryType to a string matching the
enum's value names, but instead returns a human readable descriptive
string. Let's make it clearer what this, by including "description" in
the name.
- Rename to unit_invalidate_cgroup_bpf_firewall() to make it clear
that this is about CGROUP_CONTROLLER_BPF_FIREWALL only
- Report whether things changed in unit_invalidate_cgroup()
to avoid duplicate checks
Christian made this possible in Linux 6.15 with a new system call
open_tree_attr() that combines open_tree() and mount_setattr().
Because idmapped mounts are (rightfully) not nested, we have to do
some extra shenanigans to make source we're putting the right source
uid in the userns for any idmapped mounts that we do in nspawn.
Of course we also add the necessary boilerplate to make open_tree_attr()
available in our code and wrap open_tree_attr() and the corresponding
fallback in a new function which we then use everywhere else.
struct timex is defined by sys/timex.h -> bits/timex.h.
Glibc includes the header in time.h, but let's explicitly include it
when the struct is used.
Similar to 4f18ff2e29, but for sys/timex.h.
These source files uses symbols provided by sys/stat.h, e.g. struct stat,
S_IFREG, S_IFBLK, and so on. Let's explicitly include sys/stat.h where
necessary.
Glibc's fcntl.h includes bits/stat.h, which provides these symbols, so
these symbols can be used without explicitly including sys/stat.h. But,
based on the discussion in #37922, we should explicitly include relevant
headers, and should not rely on the indirect inclusion.
Similar to 4f18ff2e29, but for sys/stat.h.
For some fields, we perform careful parsing and verification on the sender
side. For other fields, we accept any string or strv. I think that actually
this is fine: we should optimize for the correct case, i.e. the user runs a
command that is valid. The server must perform parsing in all cases, so doing
the verification on the sender side doesn't add value. When doing parsing
locally, in case of invalid or unsupported input, we would generate the error
message locally, so we would avoid the D-Bus call, but the message itself is
not better and from the user's point of view, the result is the same. And by
doing the parsing only on the server side, we deal better with the case where
the sender has an older version of the software. By not doing verification, we
implicitly "support" new values. And when the sender has a newer version that
supports additional fields, that does not help as long as the server uses an
older version. So in case of version mismatches, parsing on the server side is
as good or better.
Resolves https://github.com/systemd/systemd/issues/37174.
This changes little in behaviour, the conceptual part is more important. The
non-Ex variant is the actual name on the command line, and we should use the
non-Ex D-Bus property too, if it works. This increases compatibility with old
versions. But the code was mostly doing the right thing. Even the tests tested
the right thing.
Follow-up for b3d593673c and
898fc00e79.
The test is simplified by taking advantage of the fact that both names
on the commandline are supposed to behave identically.
Partially resolves https://github.com/systemd/systemd/issues/37174.
We generally want to have error messages with a fixed structure that convey the
important information, i.e. field name, error value, and the offending text for
options that take short values. (The text is not printed for strings encoded with
base64 and hexmem or for credentials.)
Let's use a helper that prints the message in a fixed format in the majority of
cases. In the few places where a custom message is useful, the helper is not
used. The helper:
- prints the field name, value, and error info,
- quotes the value,
- handles -ENOMEM, so we don't need to handle it separately everywhere.
When this code was originally written, parse functions would return -1
as error. Nowadays day all return a good errno, so it is fine if we print
the corresponding strerror.
exec_command_flags_to_strv() should not fail, unless we screwed up, so assert
instead of returning an error. Also, no need to strdup constant _PATH_BSHELL;
drop that so that we can get rid of the oom error handling. Finally, rename
l → cmdline for clarity.
If one of the header is included in a C++ source file, then using
_Static_assert() triggers compile error for some reasons.
Let's use static_assert(), which can be used by both C and C++ code.
Lennart Poettering
Yu Watanabe
Andres Beltran
Mike Yuan
DaanDeMeyer
Zbigniew Jędrzejewski-Szmek
dependabot[bot]