Inspired by #12431 let's also rework chmod_and_chown() and make sure we
never add more rights to a file not owned by the right user.
Also, let's make chmod_and_chown() just a wrapper arond
fchmod_and_chown().
let's also change strategy: instead of chown()ing first and stating
after on failure and supressing errors, let's avoid the chown in the
firts place, in the interest on keeping things minimal.
This restores show_pid_array() output in legacy locales on the console.
Only one call to get_process_cmdline() is changed, all others retain
utf8-only mode. This affects systemd-cgls, systemctl status, etc, when
working locally.
Calls to get_process_cmdline() that cross a process boundary always use
utf8. It's the callers responsibility to convert this to some encoding that
they use. This means that we always pass utf8 over the bus.
It turns out that the kernel allows comm names higher than our expected limit
of 16.
$ wc -c /proc/*/comm|sort -g|tail -n3
35 /proc/1292317/comm
35 /proc/1293610/comm
36 /proc/1287112/comm
$ cat /proc/1287112/comm
kworker/u9:3-kcryptd/253:0
The functions to retrieve and print process cmdlines were based on the
assumption that they contain printable ASCII, and everything else
should be filtered out. That assumption doesn't hold in today's world,
where people are free to use unicode everywhere.
This replaces the custom cmdline reading code with a more generic approach
using utf8_escape_non_printable_full().
For kernel threads, truncation is done on the parenthesized name, so we'll
get "[worker]", "[worker…]", …, "[w…]", "[…", "…" as we reduce the number of
available columns.
This implementation is most likely slower for very long cmdlines, but I don't
think this is very important. The common case is to have short commandlines,
and should print those properly. Absurdly long cmdlines are the exception,
which needs to be handled correctly and safely, but speed is not too important.
Fixes#12532.
v2:
- use size_t for the number of columns. This change propagates into various
other functions that call get_process_cmdline(), increasing the size of the
patch, but the changes are rather trivial.
Previously used "highlight yellow" was not visible on urxvt, because it
was too light. This color is shown as bold black by urxvt, but at least
it is readable. On other terminals it is shown as various hues of yellow,
pleasant on the eyes and not too bright. The color shown on linux console
could be called orange rather than yellow, but it is still readable.
(I also tried non-highlight "yellow", but it is not as readable.)
This is a follow-up for bb40c12569.
Fix the following compile error:
src/basic/socket-util.h:187:30: error: implicit declaration of function 'strnlen'; did you mean 'strlen'? [-Werror=implicit-function-declaration]
Switching to K_UNICODE from other than L_XLATE can make the keyboard
unusable and possibly leak keypresses from X.
BugLink: https://launchpad.net/bugs/1803993
An ugly, ugly work-around for #11810. And no, we shouldn't have to do
this. This is something for AMD, the firmware or the kernel to
fix/work-around, not us. But nonetheless, this should do it for now.
Fixes: #11810
We don#t actually use all combinations, but it's kinda nice if we can
output all combinations in a test, and this is preparation so that we
can do so nicely.
three of these colors we never use, so let's drop them. Let's however
add a highlight version of grey, so that at least for all colors we do
define we have all possible styles defined.
Apparently all relevant terminals implement these sequences, including
the Linux kernel, rxvt, xterm, and of course gnome terminal. Hence it
should be OK to use them, and fixate the grey color in a way that maps
to the same color in all terminals.
Ideally we'd stick to the more symbolic colors that allow terminal
emulators to implement color styles, but this apparently doesn#t work,
since rxvt maps grey to something unreadable by default.
Note that this change has negative effects besides the non-themability
of the palette: the midrange grey this uses maps to regular white on the
linux console. However, that's probably not too bad: allowing things to
be unreadable on some terminals is probably worse than showing no color
on some terminals.
Fixes: #12482
Otherwise, the fuzzers will fail to compile with MSan:
```
../../src/systemd/src/basic/random-util.c:64:40: error: use of undeclared identifier 'sucess'; did you mean 'success'?
msan_unpoison(&success, sizeof(sucess));
^~~~~~
success
../../src/systemd/src/basic/alloc-util.h:169:50: note: expanded from macro 'msan_unpoison'
^
../../src/systemd/src/basic/random-util.c:38:17: note: 'success' declared here
uint8_t success;
^
1 error generated.
[80/545] Compiling C object 'src/basic/a6ba3eb@@basic@sta/process-util.c.o'.
ninja: build stopped: subcommand failed.
Fuzzers build failed
```
In program output, highlighting warnings with ANSI_HIGHLIGHT is not enough,
because it doesn't stand out enough. Yellow is more appropriate.
I was worried that yellow wouldn't be visible on white background, but (at
least gnome-terminal) uses a fairly dark yellow that is fully legible on white
and light-colored backgrounds. We also used yellow in many places,
e.g. systemctl, so this should be fine.
Note: yellow is unreadable on urxvt with white background (urxvt +rv). But
grey, which we already used, is also unreadable, so urxvt users would have
to disable colors anyway, so this change does not make the problem
intrinsically worse. See
https://github.com/systemd/systemd/issues/12482#issuecomment-490374210.
Let's be a bit paranoid and hash the 16 bytes we get from getauxval()
before using them. AFter all they might be used by other stuff too (in
particular ASLR), and we probably shouldn't end up leaking that seed
though our crappy pseudo-random numbers.
The old flag name was a bit of a misnomer, as /dev/urandom cannot be
"drained". Once it's initialized it's initialized and then is good
forever. (Only /dev/random has a concept of 'draining', but we never use
that, as it's an obsolete interface).
The flag is still useful though, since it allows us to suppress accesses
to the random pool while it is not initialized, as that trips up the
kernel and it logs about any such attempts, which we really don't want.
Unfortunately the warning must be known, or otherwise the pragma generates a
warning or an error. So let's do a meson check for it.
Is it worth doing this to silence the warning? I think so, because apparently
the warning was already emitted by gcc-8.1, and with the recent push in gcc to
catch more such cases, we'll most likely only get more of those.
This is another attempt at d4b604baea and #12438
Instead of blindly using the extra allocated space, let's do so only
after telling libc about it, via a second realloc(). The second
realloc() should be quick, since it never has to copy memory around.
This reverts commit d4b604baea.
When realloc() is called, the extra memory between the originally
requested size and the end of malloc_usable_size() isn't copied. (at
least with the version of glibc that currently ships on Arch Linux)
As a result, some elements get lost and use uninitialized memory, most
commonly 0, and can lead to crashes.
fixes#12384
If a container manager does not set $container, we could end up
in a strange situation when detect-virt returns container-other when
run as non-pid-1 and none when run as pid-1.
