udev: open control and netlink sockets before daemonization
c4b69e990f962128cc6975e36e91e9ad838fa2c4 effectively moved the initalization of socket.
Before that commit:
run → listen_fds → udev_ctrl_new → udev_ctrl_new_from_fd → socket()
After:
run → main_loop → manager_new → udev_ctrl_new_from_fd → socket()
The problem is that main_loop was called after daemonization. Move manager_new
out of main_loop and before daemonization.
Fixes #11314 (hopefully ;)).
v2: Yu Watanabe
sd_event is initialized in main_loop().
journal-remote: set a limit on the number of fields in a message
Existing use of E2BIG is replaced with ENOBUFS (entry too long), and E2BIG is
reused for the new error condition (too many fields).
This matches the change done for systemd-journald, hence forming the second
part of the fix for CVE-2018-16865
(https://bugzilla.redhat.com/show_bug.cgi?id=1653861).
Calling mhd_respond(), which ulimately calls MHD_queue_response() is
ineffective at point, becuase MHD_queue_response() immediately returns
MHD_NO signifying an error, because the connection is in state
MHD_CONNECTION_CONTINUE_SENT.
As Christian Grothoff kindly explained:
> You are likely calling MHD_queue_repsonse() too late: once you are
> receiving upload_data, HTTP forces you to process it all. At this time,
> MHD has already sent "100 continue" and cannot take it back (hence you
> get MHD_NO!).
>
> In your request handler, the first time when you are called for a
> connection (and when hence *upload_data_size == 0 and upload_data ==
> NULL) you must check the content-length header and react (with
> MHD_queue_response) based on this (to prevent MHD from automatically
> generating 100 continue).
If we ever encounter this kind of error, print a warning and immediately
abort the connection. (The alternative would be to keep reading the data,
but ignore it, and return an error after we get to the end of data.
That is possible, but of course puts additional load on both the
sender and reciever, and doesn't seem important enough just to return
a good error message.)
Note that sending of the error does not work (the connection is always aborted
when MHD_queue_response is used with MHD_RESPMEM_MUST_FREE, as in this case)
with libµhttpd 0.59, but works with 0.61:
https://src.fedoraproject.org/rpms/libmicrohttpd/pull-request/1
journald: lower the maximum entry size limit to ½ for non-sealed fds
We immediately read the whole contents into memory, making thigs much more
expensive. Sealed fds should be used instead since they are more efficient
on our side.
journald: when processing a native message, bail more quickly on overbig messages
We'd first parse all or most of the message, and only then consider if it
is not too large. Also, when encountering a single field over the limit,
we'd still process the preceding part of the message. Let's be stricter,
and check size limits early, and let's refuse the whole message if it fails
any of the size limits.
journald: set a limit on the number of fields (1k)
We allocate a iovec entry for each field, so with many short entries,
our memory usage and processing time can be large, even with a relatively
small message size. Let's refuse overly long entries.
What from I can see, the problem is not from an alloca, despite what the CVE
description says, but from the attack multiplication that comes from creating
many very small iovecs: (void* + size_t) for each three bytes of input message.
coredump: fix message when we fail to save a journald coredump
If creation of the message failed, we'd write a bogus entry:
systemd-coredump[1400]: Cannot store coredump of 416 (systemd-journal): No space left on device
systemd-coredump[1400]: MESSAGE=Process 416 (systemd-journal) of user 0 dumped core.
systemd-coredump[1400]: Coredump diverted to
2MB might be hard for some clients to use meaningfully, but OTOH, it is
important to log the full commandline sometimes. For example, when the program
is crashing, the exact argument list is useful.
journald: do not store the iovec entry for process commandline on stack
This fixes a crash where we would read the commandline, whose length is under
control of the sending program, and then crash when trying to create a stack
allocation for it.
coredump: remove duplicate MESSAGE= prefix from message
systemd-coredump[9982]: MESSAGE=Process 771 (systemd-journal) of user 0 dumped core.
systemd-coredump[9982]: Coredump diverted to /var/lib/systemd/coredump/core...
log_dispatch() calls log_dispatch_internal() which calls write_to_journal()
which appends MESSAGE= on its own.
dana [Mon, 24 Dec 2018 11:15:38 +0000 (05:15 -0600)]
zsh completion: Prevent functions from clobbering each other, &c.
- Don't redefine helpers on every call
- Prefix helper names with main function name
- Adjust some helper names for consistency and convention adherance
udev: rework how we handle the return value from spawned programs
When running PROGRAM="...", we would log
systemd-udevd[447]: Failed to wait spawned command '...': Input/output error
no matter why the program actually failed, at error level.
The code wouldn't distinguish between an internal failure and a failure in the
program being called and run sd_event_exit(..., -EIO) on any kind of error. EIO
is rather misleading here, becuase it suggests a serious error.
on_spawn_sigchld is updated to set the return code to distinguish failure to
spawn, including the program being killed by a signal (a negative return value),
and the program failing (positive return value).
The logging levels are adjusted, so that for PROGRAM= calls, which are
essentially "if" statements, we only log at debug level (unless we get a
timeout or segfault or another unexpected error).
pam_systemd: set $DBUS_SESSION_BUS_ADDRESS unconditionally
There's very little lost if the variable is set for a socket that isn't
connectible, but a lot lost (races, ...) if it's not set but the socket exists.
Also, drop the FIXME note, since we don't plan to revert this revert any time
soon.
man: systemctl: document effect of --all on journal output
Based on the journalctl documentation of this option added in 23ad99b519
(#10527), but with the first reference to “fields” replaced by “journal
messages”, since I think it’s less common to show other fields with
`systemctl status` (though it’s possible with the `-o` option).
This should not be necessary anymore after previous commit.
I don't quite remember what sequence of steps was failing, but right now
"meson build -Dslow-tests=true && ninja -C build fuzzers" work fine.
Use c99 static array size declarations in exported functions too
It seems quite useful to provide this additional information in public exported
functions.
This is a c99 feature, not supported in C++. Without the check in _sd-common.h:
FAILED: test-bus-vtable-cc@exe/src_libsystemd_sd-bus_test-bus-vtable-cc.cc.o
...
In file included from ../src/libsystemd/sd-bus/test-bus-vtable-cc.cc:9:
In file included from ../src/systemd/sd-bus-vtable.h:26:
In file included from ../src/systemd/sd-bus.h:26:
../src/systemd/sd-id128.h:38:47: error: static array size is a C99 feature, not permitted in C++
char *sd_id128_to_string(sd_id128_t id, char s[static SD_ID128_STRING_MAX]);
^
In .c files, I opted to use the define for consistency, even though we don't support
compilation with a C++ compiler, so the unconditional keyword would work too.
Removing the environment variable causes problems, e.g. Xfce and Chromium and
... don't communicate with the running dbus instance. If they attempt to start their
own instance, things become even more confusing. Those packages could be fixed
one by one, but removing the variable right now is causing too many problems.
YunQiang Su [Tue, 25 Dec 2018 11:01:17 +0000 (19:01 +0800)]
Pass separate dev_t var to device_path_parse_major_minor
MIPS/O32's st_rdev member of struct stat is unsigned long, which
is 32bit, while dev_t is defined as 64bit, which make some problems
in device_path_parse_major_minor.
Don't pass st.st_rdev, st_mode to device_path_parse_major_minor,
while pass 2 seperate variables. The result of stat is alos copied
out into these 2 variables. Fixes: #11247
test-json: check absolute and relative difference in floating point test
The test fails under valgrind, so there was an exception for valgrind.
Unfortunately that check only works when valgrind-devel headers are
available during build. But it is possible to have just valgrind installed,
or simply install it after the build, and then "valgrind test-json" would
fail.
It also seems that even without valgrind, this fails on some arm32 CPUs.
Let's do the usual-style test for absolute and relative differences.
docs: add a "front matter" snippet to our markdown pages
It turns out Jekyll (the engine behind GitHub Pages) requires that pages
include a "Front Matter" snippet of YAML at the top for proper rendering.
Omitting it will still render the pages, but including it opens up new
possibilities, such as using a {% for %} loop to generate index.md instead of
requiring a separate script.
I'm hoping this will also fix the issue with some of the pages (notably
CODE_OF_CONDUCT.html) not being available under systemd.io
Tested locally by rendering the website with Jekyll. Before this change, the
*.md files were kept unchanged (so not sure how that even works?!), after this
commit, proper *.html files were generated from it.
Burt P [Sun, 30 Dec 2018 03:49:49 +0000 (21:49 -0600)]
hwdb/sdio.ids: add BCM43438 + minor rewording of class name
* BCM43438 is used in the Raspberry Pi 3 B and B+
https://www.raspberrypi.org/products/raspberry-pi-3-model-b/
"BCM43438 wireless LAN and Bluetooth Low Energy (BLE) on board"
* With this minor change to "C 00", each class name could be prefixed
with "Is a" and still make sense.
ikelos [Sat, 29 Dec 2018 19:01:10 +0000 (19:01 +0000)]
Improve kernel-install support for initrd files. (#11281)
The current support in kernel-install for initrd images doesn't copy
over the initrd file or allow a means for it to be specified (it
requires a specific filename in a particular directory).
This patchset adds support for (optionally) providing the name of
initial ramdisk file to copied over and used by kernel-install.
projects / thirdparty / systemd.git / log
