core/dbus: silence gcc warning about unitialized variable
src/core/dbus.c: In function 'find_unit':
src/core/dbus.c:334:15: warning: 'u' may be used uninitialized in this function [-Wmaybe-uninitialized]
*unit = u;
^
src/core/dbus.c:301:15: note: 'u' was declared here
Unit *u;
^
core/manager: silence gcc warning about unitialized variable
At -O3, this was printed a hundred times for various callers of
manager_add_job_by_name(). AFAICT, there is no error and `unit` is always
intialized. Nevertheless, add explicit initialization to silence the noise.
src/core/manager.c: In function 'manager_start_target':
src/core/manager.c:1413:16: warning: 'unit' may be used uninitialized in this function [-Wmaybe-uninitialized]
return manager_add_job(m, type, unit, mode, e, ret);
^
src/core/manager.c:1401:15: note: 'unit' was declared here
Unit *unit;
^
core/manager: make manager_load_unit*() functions always take output arg
We were inconsistent, manager_load_unit_prepare() would crash if _ret was ever NULL.
But none of the callers use NULL. So simplify things and require it to be non-NULL.
Hans de Goede [Sun, 12 Feb 2017 11:33:22 +0000 (12:33 +0100)]
rules: Add extended evdev/input match rules for event nodes with the same name
Sometimes a system may have 2 input event nodes with the same name where
we only want to apply keyboard hwdb rules to 1 of the 2 devices.
This problem happens e.g. on devices where the soc_button_array driver is
used (e.g. intel atom based tablets) which registers 2 event nodes with
the name "gpio-keys".
This commit adds a new extended match rule which extends the match to also
check $attr{phys} and $attr{capabilities/ev}, allowing to differentiate
between devices with an identical name.
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
core: skip ReadOnlyPaths= and other permission-related mounts on PermissionsStartOnly= (#5309)
ReadOnlyPaths=, ProtectHome=, InaccessiblePaths= and ProtectSystem= are
about restricting access and little more, hence they should be disabled
if PermissionsStartOnly= is used or ExecStart= lines are prefixed with a
"+". Do that.
(Note that we will still create namespaces and stuff, since that's about
a lot more than just permissions. We'll simply disable the effect of
the four options mentioned above, but nothing else mount related.)
This also adds a test for this, to ensure this works as intended.
No documentation updates, as the documentation are already vague enough
to support the new behaviour ("If true, the permission-related execution
options…"). We could clarify this further, but I think we might want to
extend the switches' behaviour a bit more in future, hence leave it at
this for now.
shared: pass *unsigned_long to namespace_flag_from_string_many (#5315)
Fixes:
```
src/shared/bus-unit-util.c: In function ‘bus_append_unit_property_assignment’:
src/shared/bus-unit-util.c:570:65: warning: passing argument 2 of ‘namespace_flag_from_string_many’ from incompatible pointer type [-Wincompatible-pointer-types]
r = namespace_flag_from_string_many(eq, &flags);
^
In file included from src/shared/bus-unit-util.c:31:0:
src/shared/nsflags.h:41:5: note: expected ‘long unsigned int *’ but argument is of type ‘uint64_t * {aka long long unsigned int *}’
int namespace_flag_from_string_many(const char *name, unsigned long *ret);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Florian Klink [Fri, 10 Feb 2017 23:47:55 +0000 (00:47 +0100)]
networkd: add IPv6ProxyNDPAddress support (#5174)
IPv6 Neighbor discovery proxy is the IPv6 equivalent to proxy ARP for IPv4.
It is required when ISPs do not unconditional route IPv6 subnets
to their designated target, but expect neighbor solicitation messages
for every address on a link.
A variable IPv6ProxyNDPAddress= is introduced to the [Network] section,
each representing a IPv6 neighbour proxy entry in the neighbour table.
Dan Streetman [Fri, 10 Feb 2017 20:29:23 +0000 (15:29 -0500)]
test: create sys-script.py script
The script contains the contents of all sys/ test files, and creates
all dirs/links/files when run. This replaces the sys.tar.xz tarball
that contained sys/, so changes to sys files only require a simple
commit in git, instead of checking in an entire new tarball for each
sys/ change.
Dan Streetman [Fri, 10 Feb 2017 20:27:18 +0000 (15:27 -0500)]
test: add script to convert sys/ into sys-script.py
Instead of keeping all sys/ nodes in a tarball, use a script
"sys-script.py" to create all the sys/ entries.
This adds a script to create that initial "sys-script.py" script, using
an existing sys/ directory, created from the sys.tar.xz contents.
The "sys-script.py" can then be edited or recreated later, when any sys/
files are added or modified; the change will be only a patch to the
"sys-script.py" script in git, instead of forcing git to store a new
binary tarball.
path-lookup: if $HOME can be determined but $XDG_RUNTIME_DIR can't, is it
So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use
either, and fail acquire_config_dirs() and acquire_control_dirs() in
their entireties. With this change, let's make use of the variables we
can acquire, and don't bother with the other.
Specifically this means: in both acquire_config_dirs() and
acquire_control_dirs() handle ENXIO from user_config_dir() and
user_runtime_dir() directly, instead of propagating it up and handling
it in the caller.
path-lookup: try harder acquiring them $HOME of a user
Let's use get_home_dir() for figuring out the home directory, so that
there's a good chance we succeed figuring out unit locations even if
$HOME isn't set.
install: never hit assert() when we can't figure out where to write configuration symlinks
Under specific circumstances it might happen that we can't figure out
where to place our symlinks, for example because we are supposed to
create them in the runtime directory but $XDG_RUNTIME_DIR is not set. In
this case, return -ENXIO instead of hitting an assert().
(Yeah, the error isn't very descriptive, but for now this should at
least be good enough to remove the assert() being hit.)
install: when disabling units, do so even if the unit is missing
In some cases there might be unit symlinks in .wants/ or .requires/
directories even though the unit is otherwise fully removed. In this
case, don't fail removal, but still remove the symlinks.
This reworks the symlink marking logic to always add unit files that we
are missing to the changes list, but proceed with any symlink removal
for them. This way we'll still generate useful hints that a unit is
missing if you invoke "systemctl disable idontexist.service", but also
still remove any link to it.
dbus: permit seeing process list of units whose unit files are missing
Previously, we'd refuse the GetUnitProcesses() bus call if the unit file
couldn't be loaded. Which is wrong, as admins should be able to inspect
services whose unit files was deleted. Change this logic, so that we
permit introspecting the processes of any unit that is loaded,
regardless if it has a unit file or not.
(Note that we won't load unit files in GetUnitProcess(), but only
operate on already loaded ones. That's because only loaded units can
have processes — as that's how our GC logic works — and hence loading
the unit just for the process tree is pointless, as it would be empty).
After generating the template name we can shortcut things and just call
unit_file_find_dirs() from inside itself, just with the new name and
save a good number of duplicate lines.
man: improve documentation on seccomp regarding alternative ABIs
Let's clarify that RestrictAddressFamilies= and MemoryDenyWriteExecute=
are only fully effective if non-native system call architectures are
disabled, since they otherwise may be used to circumvent the filters, as
the filters aren't equally effective on all ABIs.
resolved: also synthesize records for the full local hostname
Previously, we'd only synthesize RRs for the LLMNR and mDNS versions of
the hostnames (i.e. the first label of the kernel hostname, as well as
the first label of the kernel hostname suffixed with .local). With this
change, we also synthesize an RR for the full hostname, which is
relevant in case it has more than one label.
Clients expect us to follow CNAMEs for them, hence do so. On the first
iteration start putting together a packet, and then keep adding data we
acquire through CNAMEs to it, until we finally send it off.
execute: set working directory to /root if User= is not set, but WorkingDirectory=~ is
Or actually, try to to do the right thing depending on what is
available:
- If we know $HOME from User=, then use that.
- If the UID for the service is 0, hardcode that WorkingDirectory=~ means WorkingDirectory=/root
- In any other case (which will be the unprivileged --user case), use
get_home_dir() to find the $HOME of the user we are running as.
- Otherwise fail.
David Glasser [Wed, 8 Feb 2017 23:12:36 +0000 (15:12 -0800)]
man: fix docs for swap's DefaultDependencies= (#5278)
There was a missing dependency and one with the wrong type. Additionally, refer
to DefaultDependencies= once instead of twice, without a vague reference in the
first one that doesn't mention that the value matters.
seccomp: on s390 the clone() parameters are reversed
Add a bit of code that tries to get the right parameter order in place
for some of the better known architectures, and skips
restrict_namespaces for other archs.
This also bypasses the test on archs where we don't know the right
order.
In this case I didn't bother with testing the case where no filter is
applied, since that is hopefully just an issue for now, as there's
nothing stopping us from supporting more archs, we just need to know
which order is right.
Franck Bui [Wed, 8 Feb 2017 19:56:22 +0000 (20:56 +0100)]
sd-event: "when exiting no signal event are pending" is a wrong assertion (#5271)
The code make the following assertion: when freeing a event loop object
(usually it's done after exiting from the main event loop), no signal events
are still queued and are pending.
This assertion can be found in event_unmask_signal_data() with
"assert(!d->current);" assertion.
It appears that this assertion can be wrong at least in a specific case
described below.
Consider the following example which is inspired from udev: a process defines 3
source events: 2 are created by sd_event_add_signal() and 1 is created by
sd_event_add_post().
1. the process receives the 2 signals consecutively so that signal 'A' source
event is queued and pending. Consequently the post source event is also
queued and pending. This is done by sd_event_wait().
2. The callback for signal 'A' is called by sd_event_dispatch().
3. The next call to sd_event_wait() will queue signal 'B' source event.
4. The callback for the post source event is called and calls sd_event_exit().
5. the event loop is exited.
6. freeing the event loop object will lead to the assertion failure in
event_unmask_signal_data().
This patch simply removes this assertion as it doesn't seem to be a
bug if the signal data still reference a signal source at this point.
Philip Withnall [Wed, 8 Feb 2017 15:54:31 +0000 (15:54 +0000)]
nspawn: Add support for sysroot pivoting (#5258)
Add a new --pivot-root argument to systemd-nspawn, which specifies a
directory to pivot to / inside the container; while the original / is
pivoted to another specified directory (if provided). This adds
support for booting container images which may contain several bootable
sysroots, as is common with OSTree disk images. When these disk images
are booted on real hardware, ostree-prepare-root is run in conjunction
with sysroot.mount in the initramfs to achieve the same results.
Philip Withnall [Wed, 8 Feb 2017 15:53:01 +0000 (15:53 +0000)]
test: Fix a maybe-uninitialised compiler warning (#5269)
The compiler warning is a false positive, since n_addresses is always
initialised on the success path from parse_argv(), but the compiler
obviously can’t work that out.
Fixes:
src/test/test-nss.c:426:9: warning: 'n_addresses' may be used uninitialized in this function [-Wmaybe-uninitialized]
dissect: don't honour NOAUTO flags when looking for ESP (#5224)
The flag is originally defined for "basic data partitions", but not for the
ESP. We reuse it for the various partitions defined by the Discoverable
Partitions Spec, but it isn't defined for the ESP, hence don't check for
it. Instead, do check for GPT_FLAG_NO_BLOCK_IO_PROTOCOL, as that flag
actually is defined for all partition types, and recommended to use by
the UEFI spec.
Franck Bui [Fri, 27 Jan 2017 15:02:22 +0000 (16:02 +0100)]
tests: add dropin dependency tests
[zj: tests assertions adjusted to the different logic in which masking
of a dependency through one name, does not forbid the dependency
being added through another name.]
core/load-dropin: add more sanity checks on .wants/.requires symlinks
Feb 04 22:35:42 systemd[1462]: foo.service: Wants dependency dropin /home/zbyszek/.config/systemd/user/foo.service.wants/diffname.service target ../barbar.service has different name
Feb 04 22:35:42 systemd[1462]: foo.service: Wants dependency dropin /home/zbyszek/.config/systemd/user/foo.service.wants/wrongname is not a valid unit name, ignoring
core: implement masking of .wants/.requires symlinks
Fixes #1169.
Fixes #4830.
Example log errors:
Feb 04 22:13:28 systemd[1462]: foo.service: Wants dependency on empty_file.service is masked by /home/zbyszek/.config/systemd/user/foo.service.wants/empty_file.service, ignoring
Feb 04 22:13:28 systemd[1462]: foo.service: Wants dependency on masked.service is masked by /home/zbyszek/.config/systemd/user/foo.service.wants/masked.service, ignoring
core: when loading .wants and .requires, follow the same logic as .d conf dropins
Essentially, instead of sequentially adding deps based on all symlinks
encountered in .wants and .requires dirs for each name and each unit file load
path, iteratate over the load paths and unit names gathering symlinks, then
order them based on priority, and then iterate over the final list, adding
dependencies.
This patch doesn't change the logic too much, except that the order in which
dependencies are applied might be different. It wasn't defined before, so that
not really a change. Adding filtering on the symlinks is left for later
patches.
The --help text currently uses the "--umount" spelling, hence to the
same in the man page too.
And let's settle on "umount" instead of "unmount" here, since most folks
probably expect that when typing in a command, as util-linux' tool is
called "umount" after all, and so is the symlink "systemd-umount" we
install.
lewo [Tue, 7 Feb 2017 23:56:55 +0000 (00:56 +0100)]
tmpfiles.d: set primary group rights to r-w (#5265)
If the /var/log/journal directory is created with rigths 700, the application
of an ACL rules without any primary group right sets it to 0. A chmod 755 on
this file will then only set the ACL mask and let the ACL primary group right
to 0. The directory is then unreadable for the primary group.
This patch explicitly sets the primary group to avoid this problem.
projects / thirdparty / systemd.git / log
