| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
It's handled just fine by returning NULL.
|
|
-ENOENT is the same return value as if 'other' were an allocated hashmap
that does not contain the key. A NULL hashmap is a possible way of
expressing a hashmap that contains no key.
|
|
Test more corner cases and error states in several tests.
Add new tests for:
hashmap_move
hashmap_remove
hashmap_remove2
hashmap_remove_value
hashmap_remove_and_replace
hashmap_get2
hashmap_first
In test_hashmap_many additionally test with an intentionally bad hash
function.
|
|
test-hashmap-ordered.c is generated from test-hashmap-plain.c simply by
substituting "ordered_hashmap" for "hashmap" etc.
In the cases where tests rely on the order of entries, a distinction
between plain and ordered hashmaps is made using the ORDERED macro,
which is defined only for test-hashmap-ordered.c.
|
|
Few Hashmaps/Sets need to remember the insertion order. Most don't care
about the order when iterating. It would be possible to use more compact
hashmap storage in the latter cases.
Add OrderedHashmap as a distinct type from Hashmap, with functions
prefixed with "ordered_". For now, the functions are nothing more than
inline wrappers for plain Hashmap functions.
|
|
new mac_{smack,selinux,apparmor}_xyz() convention
|
|
|
|
move label apis to selinux-util.ch or smack-util.ch appropriately.
|
|
|
|
Even when termninated normally, systemd-journal-upload would return
something positive which would be interpreted as failure.
|
|
Repetetive messages can be annoying when running with
SYSTEMD_LOG_LEVEL=debug, but they are sometimes very useful
when debugging problems. Add log_trace which is like log_debug
but becomes a noop unless LOG_TRACE is defined during compilation.
This makes it easy to enable very verbose logging for a subset
of programs when compiling from source.
|
|
|
|
Precision of INT_MAX does not work as I expected it to.
https://bugzilla.redhat.com/show_bug.cgi?id=1154334
|
|
Do our best verify that we can actually write the state file
before upload commences to avoid duplicate messages on the server.
|
|
socknameinfo_pretty() would fail for addresses without reverse DNS,
but we do not want that to happen.
|
|
|
|
Return a proper code instead of simply NULL for failure.
|
|
|
|
|
|
This possibility was recently added, and it makes debugging much nicer.
|
|
|
|
Systemd 209 started setting $WATCHDOG_PID, and sd-daemon watch was
modified to check for this variable. This means that
sd_watchdog_enabled() stopped working with previous versions of
systemd. But sd-event is a public library and API and we must keep it
working even when a program compiled with a newer version of the
libary is used on a system running an older version of the manager.
getenv() and unsetenv() are fairly expensive calls, so optimize
sd_watchdog_enabled() by not calling them when unnecessary.
man: centralize the description of $WATCHDOG_PID and $WATCHDOG_USEC in
the sd_watchdog_enabled manpage. It is better not to repeat the same
stuff in two places.
|
|
Evidently some people had trouble finding it in the documentation.
|
|
root password
|
|
|
|
|
|
systemd-journal-flush.service
This new command will ask the journal daemon to flush all log data
stored in /run to /var, and wait for it to complete. This is useful, so
that in case of Storage=persistent we can order systemd-tmpfiles-setup
afterwards, to ensure any possibly newly created directory in /var/log
gets proper access mode and owners.
|
|
|
|
string_is_safe()
After all, we know have this as generic validator, so let's be correct
and use it wherver applicable.
|
