pam_systemd: don't use PAM_SYSTEM_ERR for something that isn't precisely a system error
It's not really clear which PAM errors to use for which conditions, but
something called PAM_SYSTEM_ERR should probably not be used when the
error is not the result of some system call failure.
This cleans up and unifies the outut of --help texts a bit:
1. Highlight the human friendly description string, not the command
line via ANSI sequences. Previously both this description string and
the brief command line summary was marked with the same ANSI
highlight sequence, but given we auto-page to less and less does not
honour multi-line highlights only the command line summary was
affectively highlighted. Rationale: for highlighting the description
instead of the command line: the command line summary is relatively
boring, and mostly the same for out tools, the description on the
other hand is pregnant, important and captions the whole thing and
hence deserves highlighting.
2. Always suffix "Options" with ":" in the help text
3. Rename "Flags" → "Options" in one case
4. Move commands to the top in a few cases
5. add coloring to many more help pages
6. Unify on COMMAND instead of {COMMAND} in the command line summary.
Some tools did it one way, others the other way. I am not sure what
precisely {} is supposed to mean, that uppercasing doesn't, hence
let's simplify and stick to the {}-less syntax
core/path: fix spurious triggering of PathExists= on restart/reload
Our handling of the condition was inconsistent. Normally, we'd only fire when
the file was created (or removed and subsequently created again). But on restarts,
we'd do a "recheck" from path_coldplug(), and if the file existed, we'd
always trigger. Daemon restarts and reloads should not be observeable, in
the sense that they should not trigger units which were already triggered and
would not be started again under normal circumstances.
Note that the mechanism for checks is racy: we get a notification from inotify,
and by the time we check, the file could have been created and removed again,
or removed and created again. It would be better if we inotify would give as
an unambiguous signal that the file was created, but it doesn't: IN_DELETE_SELF
triggers on inode removal, not directory entry, so we need to include IN_ATTRIB,
which obviously triggers on other conditions.
Using these IDs for message identication is one use case, but there are
others, hence let's drop the prefix, it only made sense to have while
the tool was part of journalctl.
id128: add new "-u" switch for outputting Ids in UUID format
For some unrelated stuff I wanted the machine ID in UUID format, and it
was annoying doing that manually. So let's add a switch for this, so
that this works:
man: significantly downgrade the Options section in systemd(1)
This structure of the man page originates from the time when systemd was
installed on top of sysvinit systems, and users had an actual chance to
interact with the systemd binary directly. Nowadays it is almost never called
directly, so let's properly explain this in the overview.
The Options section is moved down below the kernel command line, those options
are only needed in special circumstances. Let's refer the reader to the
description of the kernel command line options, and not duplicate the
descriptions (which makes the text longer than necessary and increases chances
for discrepancies).
Systemd is also prominently used as the user manager, let's mention that in the
Overview.
While at it, use "=" only when an argument is required as we nowadays do.
This makes the ask-password agent handling more alike the polkit agent
handling again, and introduces ask_password_agent_open_if_enabled() that
works just like the already existing polkit_agent_open_if_enabled().
Torsten Hilbrich [Tue, 12 Nov 2019 07:36:06 +0000 (08:36 +0100)]
nspawn: Allow Capability= to overrule private network setting
The commit:
a3fc6b55ac nspawn: mask out CAP_NET_ADMIN again if settings file turns off private networking
turned off the CAP_NET_ADMIN capability whenever no private networking
feature was enabled. This broke configurations where the CAP_NET_ADMIN
capability was explicitly requested in the configuration.
Changing the order of evalution here to allow the Capability= setting
to overrule this implicit setting:
Order of evaluation:
1. if no private network setting is enabled, CAP_NET_ADMIN is removed
2. if a private network setting is enabled, CAP_NET_ADMIN is added
3. the settings of Capability= are added
4. the settings of DropCapability= are removed
This allows the fix for #11755 to be retained and to still allow the
admin to specify CAP_NET_ADMIN as additional capability.
Kevin Kuehler [Thu, 14 Nov 2019 00:56:23 +0000 (16:56 -0800)]
units: set ProtectKernelLogs=yes on relevant units
We set ProtectKernelLogs=yes on all long running services except for
udevd, since it accesses /dev/kmsg, and journald, since it calls syslog
and accesses /dev/kmsg.
If we fail to start polkit, we get a message like
"org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer.",
which has no meaning for the caller of our StartUnit method. Let's just
return -EACCES.
$ systemctl start apache
Failed to start apache.service: Could not activate remote peer. (before)
Failed to start apache.service: Access denied (after)
We would only write to the field, and take the address. All *readers* were
removed in 284149392755f086d0a714071c33aa609e61505e. (The explanation for why
the field wasn't removed back then is that the patch underwent a few iterations,
with the initial version adding translation back and forth. Later versions of
the patch simply emit a warning and ignore the old value. Apparently nobody
noticed that the value became unused.)
TasksMax= and DefaultTasksMax= can be specified as percentages. We don't
actually document of what the percentage is relative to, but the implementation
uses the smallest of /proc/sys/kernel/pid_max, /proc/sys/kernel/threads-max,
and /sys/fs/cgroup/pids.max (when present). When the value is a percentage,
we immediately convert it to an absolute value. If the limit later changes
(which can happen e.g. when systemd-sysctl runs), the absolute value becomes
outdated.
So let's store either the percentage or absolute value, whatever was specified,
and only convert to an absolute value when the value is used. For example, when
starting a unit, the absolute value will be calculated when the cgroup for
the unit is created.
test: Disable LUKS devices from initramfs in QEMU tests
We currently use the host's kernel and initramfs in our QEMU tests.
If the host is running on an encrypted LUKS partition, then the initramfs
will have a crypttab setup looking for the particular root disk it needs to
encrypt before booting into the system.
However, this disk obviously doesn't exist in our QEMU VM, so it turns out
our tests end up waiting for this device to become available, which will
never actually happen, and boot hangs for 90s until that service times out.
[*** ] A start job is running for /dev/disk/by-uuid/01234567-abcd-1234-abcd-0123456789ab (20s / 1min 30s)
In order to prevent this issue, let's pass "rd.luks=0" to disable LUKS in
the initramfs only as part of our default kernel command-line in our QEMU
tests.
This is enough to disable this behavior and prevent the timeout, while at
the same time doesn't conflict with our tests that actually check for LUKS
behavior in the systemd running under test (such as TEST-02-CRYPTSETUP).
Tested: `sudo make -C TEST-02-CRYPTSETUP/ clean setup run`
Be more specific in resolved.conf man page with regard to DNSOverTLS
DNSOverTLS in strict mode (value yes) does check the server, as it is said in
the first few lines of the option documentation. The check is not performed in
"opportunistic" mode, however, as that is allowed by RFC 7858, section "4.1.
Opportunistic Privacy Profile".
> With such a discovered DNS server, the client might or might not validate the
> resolver. These choices maximize availability and performance, but they leave
> the client vulnerable to on-path attacks that remove privacy.
This partially reverts db11487d1062655f17db54c4d710653f16c87313 (the logic to
calculate the correct value is removed, we always use the same setting as for
the system manager). Distributions have an easy mechanism to override this if
they wish.
I think making this configurable is better, because different distros clearly
want different defaults here, and making this configurable is nice and clean.
If we don't make it configurable, distros which either have to carry patches,
or what would be worse, rely on some other configuration mechanism, like
/etc/profile. Those other solutions do not apply everywhere (they usually
require the shell to be used at some point), so it is better if we provide
a nice way to override the default.
HATAYAMA Daisuke [Wed, 13 Nov 2019 11:30:58 +0000 (06:30 -0500)]
verify: fix segmentation fault
systemd-analyze verify command now results in segmentation fault if two
consecutive non-existent unit file names are given:
# ./build/systemd-analyze a.service b.service
...<snip irrelevant part>...
Unit a.service not found.
Unit b.service not found.
Segmentation fault (core dumped)
The cause of this is a wrong handling of return value of
manager_load_startable_unit_or_warn() in verify_units() in failure case.
It looks that the current logic wants to assign the first error status
throughout verify_units() into variable r and count up variable count only when
a given unit file exists.
However, due to the wrong handling of the return value of
manager_load_startable_unit_or_warn() in verify_units(), the variable count is
unexpectedly incremented even when there is no such unit file because the
variable r already contains non-zero value in the 2nd failure, set by the 1st
failure, and then the condition k < 0 && r == 0 evaluates to false.
This commit fixes the wrong handling of return value of
manager_load_startable_unit_or_warn() in verify_units().
cryptsetup-generator: allow overriding /run/systemd/cryptsetup with $RUNTIME_DIRECTORY
I added a fairly vague entry to docs/ENVIRONMENT because I think it is worth
mentioning there (in case someone is looking for any environment variable that
might be relevant).
projects / thirdparty / systemd.git / log
