| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
In order to make object destruction easier (in particular in combination
with _cleanup_) we usually make destructors deal with NULL objects as
NOPs. Change the calendar spec destructor to follow the same scheme.
|
|
fail if we can't set it
This partially undos 2f905e821e0342c36f5a5d3a51d53aabccc800bd
|
|
|
|
|
|
If selinux is disabled and smack is only enabled, smack label is
relable-ed by label_fix. To avoid, make only be labeled for selinux.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=84931
|
|
|
|
|
|
|
|
|
|
Using "their" as pronoun in these places is confusing since it is more
associated with plural rather than singular, and the sentence already
contains a plural. The word "her/his" apparently offends some people,
hence let's avoid the problem altogether and just name the noun again.
|
|
|
|
Fix a bug in systemd-cryptsetup-generator which caused the drop-in
setting the job timeout for the dm device unit to be written with a
name different than the unit name.
https://bugs.freedesktop.org/show_bug.cgi?id=84409
|
|
Since commit b1e90ec515408aec2702522f6f68c4920b56375b systemd passes
its log settings to systemd-shutdown via command line parameters.
However, systemd-shutdown doesn't pass these parameters to
/run/initramfs/shutdown, causing it to fall back to the default log
settings.
This fixes the following bugs about the shutdown not being quiet
despite "quiet" being in the kernel parameters:
https://bugs.freedesktop.org/show_bug.cgi?id=79582
https://bugs.freedesktop.org/show_bug.cgi?id=57216
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Normally we shouldn#t log from "library" functions, but SELinux is
weird, hence upgrade security messages uniformly to LOG_ERR when in
enforcing mode.
|
|
APIs that query and return something cannot silently fail, they must
either return something useful, or an error. Fix that.
Also, properly rollback socket unit fd creation when something goes
wrong with the security framework.
|
|
|
|
|
|
of the matching selinux code
|
|
previously mac_smack_apply(path, NULL) would operate on the symlink
itself while mac_smack_apply(path, "foo") would follow the symlink.
Let's clean this up an always operate on the symlink, which appears to
be the safer option.
|
|
a) always return negative errno error codes
b) always become a noop if smack is off
c) always take a NULL label as a request to remove it
|
|
and all that reset it to defaults mac_{selinux|smack}_fix()
Let's clean up the naming schemes a bit and use the same one for SMACK
and for SELINUX.
|
|
|
|
|
|
Just some minor nits that I stumbled over when reading the man page.
|
|
|
|
It cannot fail in the current hashmap implementation, but it may fail in
alternative implementations (unless a sufficiently large reservation has
been placed beforehand).
|
|
With the hashmap implementation that uses chaining the reservations
merely ensure that the merging won't result in long bucket chains.
With a future alternative implementation it will additionally reserve
memory to make sure the merging won't fail.
|
|
That hashmap_move_one() currently cannot fail with -ENOMEM is an
implementation detail, which is not possible to guarantee in general.
Hashmap implementations based on anything else than chaining of
individual entries may have to allocate.
hashmap_move_one will not fail with -ENOMEM if a proper reservation has
been made beforehand. Use reservations in install.c.
In cgtop.c simply propagate the error instead of asserting.
|
|
|
|
With the current hashmap implementation that uses chaining, placing a
reservation can serve two purposes:
- To optimize putting of entries if the number of entries to put is
known. The reservation allocates buckets, so later resizing can be
avoided.
- To avoid having very long bucket chains after using
hashmap_move(_one).
In an alternative hashmap implementation it will serve an additional
purpose:
- To guarantee a subsequent hashmap_move(_one) will not fail with
-ENOMEM (this never happens in the current implementation).
|
|
Return 0 if no resize was needed, 1 if successfully resized and
negative on error.
|
|
|
|
on_conflict_dispatch() uses hashmap_steal_first() and then does
something non-trivial with it. It may care about the order.
|
|
The way process_closing() picks the first entry from reply_callbacks
and works with it makes it likely that it cares about the order.
|
|
Anything that uses hashmap_next() almost certainly cares about the order
and needs to be an OrderedHashmap.
|
|
Order matters here. It replaces oldest entries first when
USER_JOURNALS_MAX is reached.
|
|
The order of entries may matter here. Oldest entries are evicted first
when the cache is full.
(Though I don't see anything to rejuvenate entries on cache hits.)
|
|
It appears order may matter here. Use OrderedHashmaps to be safe.
|
