Age | Commit message (Collapse) | Author |
|
If you've got SELinux policy loaded, label_hnd is your labeling handle.
When systemd is shutting down, we free that handle via mac_selinux_finish().
But: switch_root() calls mkdir_p_label(), which tries to look up a label
using that freed handle, and so we get a bunch of garbage and eventually
SEGV in libselinux.
(This doesn't happen in the switch-root from initramfs to real root because
there's no SELinux policy loaded in initramfs, so label_hnd is NULL and we
never attempt any lookups.)
So: make sure that mac_selinux_finish() actually sets label_hnd to NULL, so
nobody tries to use it after it becomes invalid.
https://bugzilla.redhat.com/show_bug.cgi?id=1185604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All hail linkchecker!
|
|
Coverity was complaining that CMSG_NXTHDR is used without
checking the return value. In this case it cannot fail, but
it is a good excuse to simplify the function a bit.
CID #1261726.
|
|
The data comes from the kernel, so chances of it being
garbled are low, but for correctness' sake, add the check.
CID #996458.
|
|
|
|
CID #1237623.
|
|
CID #1261729.
|
|
CID #1264371.
|
|
CID #996308.
|
|
CID #1237545.
|
|
CID #1237548.
|
|
CID #1237550.
|
|
This shouldn't really happen, but it's seems cleaner to
continue on error.
CID #1237552.
|
|
/dev/pts/ptmx is as important as /dev/pts, so error out if that
fails. Others seem less important, since the namespace is usable
without them, so ignore failures.
CID #123755, #123754.
|
|
We were using a space more often than not, and this way is
codified in CODING_STYLE.
|
|
CID #1237559.
|
|
They both point to the same location, but the reader
is not forced to look back to the beginning of the function
to see that.
|
|
In reference to CID #1238956.
|
|
It certainly is everywhere on Linux, but as a courtesy
to people doing some strange cross-compilation, check
that the assumption holds.
|
|
|
|
CID #1271353.
|
|
add_mount() is OK with unknow file type, but we have to initalize
the variable to NULL not to pass garbage on error.
|
|
CID #1287141.
|
|
CID #1287142.
|
|
|
|
Instead introduce ensure_usec_initialized(), which copies the timestamp if possible otherwise
sets it to now(CLOCK_MONOTONIC).
|
|
|
|
|
|
Do not rely on nl_pid == 0, but check the groups instead. We currently avoid using
nl_pid == 0 for unicast anyway, so this should be redundant, but let's try to be
correct.
|
|
In the unlikely event that we wrap the counter, skip 0 as this is used
for broadcasts.
Suggested by Richard Maw.
|
|
Replace ENOTSUP by EOPNOTSUPP as this is what linux actually uses.
|
|
The error code is called EDEADLK, stop using legacy names like EDEADLOCK.
Note that _some_ weird architectures define them differently (namely, mips
and sparc), but on all sane architectures they're exactly the same. So
stay with the widely used code, which is EDEADLK.
|
|
There is no reason to ever use EWOULDBLOCK. It's equivalent to EAGAIN on
all architectures on linux.
|
|
EWOULDBLOCK is the same as EAGAIN, stop using it.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=89226
|
|
none/both/v4/v6 are deprecated in favour of no/yes/ipv4/ipv6.
https://bugs.freedesktop.org/show_bug.cgi?id=89221
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=89559
|
|
|
|
journal-remote buffers input, and then parses it handling one journal entry at a time.
It was possible for useful data to be left in the buffer after some entries were
processesed. But all data would be already read from the fd, so there would be
no reason for the event loop to call the handler again. After some new data came in,
the handler would be called again, and would then process the "old" data in the buffer.
Fix this by enabling a handler wherever we process input data and do not exhaust data
from the input buffer (i.e. when EAGAIN was not encountered). The handler runs until
we encounter EAGAIN.
Looping over the input data is done in this roundabout way to allow the event loop
to dispatch other events in the meanwhile. If the loop was inside the handler, a
source which produced data fast enough could completely monopolize the process.
https://bugs.freedesktop.org/show_bug.cgi?id=89516
|
|
This matches similar code elsewhere.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=89486
|
|
|