The original issue with this transformation was that we were replacing
the whole if statement instead of just the expression inside. That
caused the code to be weirdly formatted, as Coccinelle put a new block
around each replaced if statement.
This version replaces just the inner expression if it's in its incorrect
form, otherwise it just accepts it (to avoid recursion).
nspawn: don't chown() stdin/stdout passed in when --console=pipe is used
We should chown what we allocate ourselves, i.e. any pty we allocate
ourselves. But for stuff we propagate, let's avoid that: we shouldn't
make more changes than necessary.
ptyfwd: reopen stdin/sdout before setting O_NONBLOCK
If we set O_NONBLOCK on stdin/stdout directly this means the flag is
left set when we abort abnormally, as we don't get the chance to reset
it again on exit. This might confuse progrms invoking us. Moreover, if
programs invoking us continue to write to the stdout passed to us, they
might be confused by non-blocking mode too.
Hence, let's avoid this if possible: let's reopen stdin/stdout and set
O_NONBLOCK only on the reopend fds, leaving the original fds as they
are.
sysusers: emit warnings about login.defs overrides on first user or group creation
*** Running /home/zbyszek/src/systemd-work/test/test-sysusers/test-14.input (with login.defs symlinked)
login.defs specifies UID allocation range 401–555 that is different than the built-in defaults (201–998)
login.defs specifies GID allocation range 405–666 that is different than the built-in defaults (201–990)
sysusers: look at login.defs when setting the default range to allocate users
Also, even if login.defs are not present, don't start allocating at 1, but at
SYSTEM_UID_MIN.
Fixes #9769.
The test is adjusted. Actually, it was busted before, because sysusers would
never use SYSTEM_GID_MIN, so if SYSTEM_GID_MIN was different than
SYSTEM_UID_MIN, the tests would fail. On all "normal" systems the two are
equal, so we didn't notice. Since sysusers now always uses the minimum of the
two, we only need to substitute one value.
We were looking at ${f%.*}, i.e. the $f with any suffix starting with a dot removed.
This worked fine for paths like /some/path/test-11.input. It also worked
for paths like /some/path/inline (there were no dots, so we got $f back unscathed).
But in the ubuntu CI the package is built in a temporary directory like
/tmp/autopkgtest-lxc.nnnfqb26/downtmp/build.UfW/ (yes, it has a dot, even two.).
That still worked for the first case, but in the second case we truncated things
after the first dot, and we would try to get
/tmp/autopkgtest-lxc.nnnfqb26/downtmp/build and try to load
/tmp/autopkgtest-lxc.nnnfqb26/downtmp/build.expected-password, which obviously
didn't work as expected. To avoid this issue, do the suffix removal only when
we know that there really is a suffix.
A second minor issue was that we would try to copy $1.expected-*, and sometimes
$1 would be given, and sometimes not. Effectively we were relying on there
not being any files matching .expected-*. There weren't any such files, but let's
avoid this ugliness and always pass $1.
All this test does is manipulate text files in a subdir specified with --testroot.
It can be a normal unittest without the overhead of creating a machine image.
We don't (and shouldn't I think) look at them when determining the type of the
user, but they should be used during user/group allocation. (For example, an
admin may specify SYS_UID_MIN==200 to allow statically numbered users that are
shared with other systems in the range 1–199.)
Look at /etc/login.defs for the system_max_[ug]id values
It makes little sense to make the boundary between systemd and user guids
configurable. Nevertheless, a completely fixed compile-time define is not
enough in two scenarios:
- the systemd_uid_max boundary has moved over time. The default used to be
500 for a long time. Systems which are upgraded over time might have users
in the wrong range, but changing existing systems is complicated and
expensive (offline disks, backups, remote systems, read-only media, etc.)
- systems are used in a heterogenous enviornment, where some vendors pick
one value and others another.
So let's make this boundary overridable using /etc/login.defs.
THis doesn't change the condition's logic at all, but is an attempt to
make things a bit more readable: instead of checking log_target !=
LOG_TARGET_AUTO let's actually list the targets where we want to
consider journal/syslog/kmsg, to make things a bit less confusing. After
all the message here is not to avoid them if LOG_TARGET_AUTO is set, but
to definitely do them in the other cases.
projects / thirdparty / systemd.git / log
