| Age | Commit message (Collapse) | Author |
|---|
|
|
|
sed -i 's|Linux Boot Manager|Systemd Boot Manager|' src/boot/bootctl.c
|
|
|
|
|
|
|
|
|
|
We have to pass addresses of changes and n_changes to
bus_deserialize_and_dump_unit_file_changes(). Otherwise we are hit by
missing information (subsequent calls to unit_file_changes_add() to
not add anything).
Also prevent null pointer dereference in
bus_deserialize_and_dump_unit_file_changes() by asserting.
Fixes #3339
|
|
This reverts commit 483d8bbb4c0190f419bf9fba57fb0feb1a56bea6.
In [1] Michel Dänzer and Daniel Vetter wrote:
>> The scenario you describe isn't possible if the Wayland compositor
>> directly uses the KMS API of /dev/dri/card*, but it may be possible if
>> the Wayland compositor uses the fbdev API of /dev/fb* instead (e.g. if
>> weston uses its fbdev backend).
>
> Yeah, if both weston and your screen grabber uses native fbdev API you can
> now screenshot your desktop. And since fbdev has no concept of "current
> owner of the display hw" like the drm master, I think this is not fixable.
> At least not just in userspace. Also even with native KMS compositors
> fbdev still doesn't have the concept of ownership, which is why it doesn't
> bother clearing it's buffer before KMS takes over. I agree that this
> should be reverted or at least hidden better.
TBH, I think that privilege separation between processes running under the same
UID is tenuous. Even with drm, in common setups any user process can ptrace the
"current owner of the display" and call DROP_MASTER or do whatever. It *is*
possible to prevent that, e.g. by disabling ptrace using yama.ptrace_scope, or
selinux, and so on, but afaik this is not commonly done. E.g. all Fedora
systems pull in elfutils-default-yama-scope.rpm through dependencies which sets
yama.ptrace_scope=0. And even assuming that ptrace was disabled, it is trivial
to modify files on disk, communicate through dbus, etc; there is just to many
ways for a non-sandboxed process to interact maliciously with the display shell
to close them all off. To achieve real protection, some sort of sandboxing
must be implemented, and in that case there is no need to rely on access mode
on the device files, since much more stringent measures have to be implemented
anyway.
The situation is similar for framebuffer devices. It is common to add
framebuffer users to video group to allow them unlimited access to /dev/fb*.
Using uaccess would be better solution in that case. Also, since there is no
"current owner" limitation like in DRM, processes running under the same UID
should be able to access /proc/<pid-of-display-server>/fd/* and gain access to
the devices. Nevertheless, weston implements a suid wrapper to access the
devices and then drop privileges, and this patch would make this daemon
pointless. So if the weston developers feel that this change reduces security,
I prefer to revert it.
[1] https://lists.freedesktop.org/archives/wayland-devel/2016-May/029017.html
|
|
Fixup for #3304.
Only warn, and not return, because that's what sd_dhcp6_client_start()
does right below the call to sd_dhcp6_client_set_local_address().
|
|
We'd call sd_bus_message_unref and then proceed to use
variables pointing into the reply buffer (fd and char*).
dup the fd and copy the string before destorying the reply.
This makes systemd-run run again for me.
https://bugzilla.redhat.com/show_bug.cgi?id=1337636
|
|
According to recv(2) these should be the same, but that is not true.
Passing a buffer of length 0 to read is defined to be a noop according
to read(2), but passing a buffer of length 0 to recv will discard the
pending pacet.
We can easily hit this as we allocate our buffer size depending on
the size of the incoming packet (using FIONREAD). As pointed out in
issue #3299 simply sending an empty UDP packet to the DHCP client
port will trigger a busy loop in networkd as we are polling on the
socket but never discarding the empty packet.
This reverts ad5ae47a0d159ea473c9730d7e0298a3e5d31cf6 but fixes the
same issue.
|
|
Fixes:
-bash-4.3# echo core >/proc/sys/kernel/core_pattern
-bash-4.3# kill -ABRT 1
-bash-4.3# kill -ABRT 1
[ 61.373922] systemd[1]: segfault at 7fff1d0a8f48 ip 00007fc9ca91b1c3 sp 00007fff1d0a8f50 error 6 in libc-2.23.so[7fc9ca8ce000+1c0000]
[ 61.768017] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000008b
[ 61.768017]
...
Recursive ABRT and segfault:
PID 1 - core
TID 1:
...
#153905 0x00005575fc3f829d log_dispatch
#153906 0x00005575fc3f8aa3 log_assert
#153907 0x00005575fc3f8ae9 log_assert_failed
#153908 0x00005575fc3e7eb1 safe_close
#153909 0x00005575fc3f6d5e log_close_journal
#153910 0x00005575fc3f829d log_dispatch
#153911 0x00005575fc3f85a1 log_internalv
#153912 0x00005575fc3f86a1 log_internal
#153913 0x00005575fc31c4c1 crash
#153914 0x00007fb26f2cf3d0 __restore_rt
#153915 0x00007fb26f2ced00 pause
#153916 0x00005575fc403944 freeze
#153917 0x00005575fc31bf7b freeze_or_reboot
...
|
|
Recently added cgroup helper functions break the style convention. Fix them
up.
|
|
|
|
[networkd] ndisc DHCPv6 triggering fixes
|
|
networkd: Drop IPv6LL address when link is down.
|
|
Implement compat translation between IO* and BlockIO* settings
|
|
minor improvements for dealing with MAC Addresses
|
|
free_and_strdup handles NULL but not empty strings.
See also:
https://github.com/systemd/systemd/pull/3283#issuecomment-220603145
https://github.com/systemd/systemd/pull/3307
|
|
The original conflict is fixed in the kernel in v4.6-rc7-40-g4a91cb61bb,
but now our work-around causes a compilation failure.
Keep the workaround to support 4.5 kernels for now, and layer
more ugliness on top.
Tested with:
kernel-headers-4.6.0-1.fc25.x86_64
glibc-devel-2.23.90-18.fc25.x86_64
kernel-headers-4.5.4-300.fc24.x86_64
glibc-devel-2.23.1-7.fc24.x86_64
kernel-headers-4.4.9-300.fc23.x86_64
glibc-devel-2.22-16.fc23.x86_64
kernel-headers-4.1.13-100.fc21.x86_64
glibc-devel-2.20-8.fc21.x86_64
|
|
After a few link up/down events I got this warning:
May 17 22:05:10 laptop systemd-resolved[2983]: Failed to read DNS servers for interface wlp3s0, ignoring: Argument list too long
|
|
Adds support to core for systemd D-Bus clients to send the
`SELinuxContext` property . This means `systemd-run -p
SELinuxContext=foo` should now work.
|
|
rm_rf_physical_and_freep in tests (#3292)
Some distros don't mount /tmp as tmpfs.
For example:
https://lists.ubuntu.com/archives/ubuntu-cloud/2016-January/001009.html
Some tests:
* print 'Attempted to remove disk file system, and we can't allow that.'
* don't really cleanup /tmp
|
|
|
|
dhcp6_request_address()
Starting the DHCP client doesn't seem like dhcp6_request_address()'s responsibility anyway. Whenever it's called, sd_dhcp6_client_start() is unconditionally called outside of it as well. See ndisc_router_handler() and ndisc_handler() in networkd-ndisc.c.
|
|
Fix issue #3256 and probably #1982. Referenced link_acquire_ipv6_conf() in networkd-link.c.
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=1336960
|
|
After enabling/disabling a unit, the daemon configuration is expected
to be unless '--no-reload' option is passed.
However this is not done when enabling a sysv units. This can lead to
the following scenario:
$ cp /etc/init.d/named /etc/init.d/foo
$ systemctl enable foo
foo.service is not a native service, redirecting to systemd-sysv-install
Executing /usr/lib/systemd/systemd-sysv-install enable foo
$ systemctl start foo
Failed to start foo.service: Unit foo.service failed to load: No such file or directory.
This can also be seen after installing a package providing a sysv
service: the service can't be started unless 'daemon-reload' is called
manually. This shouldn't be needed and this patch will fix this case
too since during package installation, the service is expected to be
enabled/disabled.
|
|
The sync() call on shutdown had been removed with commit 57371e5829a61e5ee6c9f98404dfc729d6c62608
together with the no-sync option for the shutdown commands.
The sync call was restored in commit 4a3ad39957399c4a30fc472a804e72907ecaa4f9 but the no-sync option
wasn't re-added.
I think we should restore this option at least for the legacy halt command.
|
|
free_and_strdup already handles the NULL case for us, so we can remove
an extraneous conditional check.
As noted in https://github.com/systemd/systemd/pull/3279/files#r63687717
|
|
Due to the substantial interface changes in cgroup unified hierarchy, new IO
settings are introduced. Currently, IO settings apply only to unified
hierarchy and BlockIO to legacy. While the transition is necessary, it's
painful for users to have to provide configs for both. This patch implements
translation from one config set to another for configs which make sense.
* The translation takes place during application of the configs. Users won't
see IO or BlockIO settings appearing without being explicitly created.
* The translation takes place only if there is no config for the matching
cgroup hierarchy type at all.
While this doesn't provide comprehensive compatibility, it should considerably
ease transition to the new IO settings which are a superset of BlockIO
settings.
v2:
- Update test-cgroup-mask.c so that it accounts for the fact that
CGROUP_MASK_IO and CGROUP_MASK_BLKIO move together. Also, test/parent.slice
now sets IOWeight instead of BlockIOWeight.
|
|
Factor out the following functions out of cgroup_context_apply()
* cgroup_context_[blk]io_weight()
* cgroup_apply_[blk]io_device_weight()
* cgroup_apply_[blk]io_device_limit()
This is pure refactoring and shouldn't cause any functional differences.
|
|
CGroupBlockIODeviceBandwith is used to keep track of IO bandwidth limits for
legacy cgroup hierarchies. Unlike the unified hierarchy counterpart
CGroupIODeviceLimit, a CGroupBlockIODeviceBandwiddth records either a read or
write limit and has a couple issues.
* There's no way to clear specific config entry.
* When configs are cleared for an IO direction of a unit, the kernel settings
aren't cleared accordingly creating discrepancies.
This patch updates CGroupBlockIODeviceBandwidth so that it behaves similarly to
CGroupIODeviceLimit - each entry records both rbps and wbps limits and is
cleared if both are at default values after kernel settings are updated.
|
|
cgroup IO controller supports maximum limits for both bandwidth and IOPS but
systemd resource control currently only supports bandwidth limits. This patch
adds support for IOReadIOPSMax and IOWriteIOPSMax when unified cgroup hierarchy
is in use.
It isn't difficult to also add BlockIOReadIOPS and BlockIOWriteIOPS for legacy
hierarchies but IO control on legacy hierarchies is half-broken anyway, so
let's leave it alone for now.
|
|
Currently, there are two cgroup IO limits, bandwidth max for read and write,
and they are hard-coded in various places. This is fine for two limits but IO
is expected to grow more limits - low, high and max limits for bandwidth and
IOPS - and hard-coding each limit won't make sense.
This patch replaces hard-coded limits with an array indexed by
CGroupIOLimitType and accompanying string and default value tables so that new
limits can be added trivially.
|
|
Now we are not dropping the IPv6LL address when link is down.
So next time when link is up and before kernel acquired this address
we are using the old address.
When the link is down kernel tells us that this address is no longer
valid . Let's remove this address and again when kernel tells us
that the address is added let's use it.
fixes #3264
|
|
This is partial fix for #2228 and #2977, #3204.
bridge-test: netdev ready
docker0: Gained IPv6LL
wlan0: Gained IPv6LL
eth0: Gained IPv6LL
Enumeration completed
bridge-test: netdev exists, using existing without changing its
parameters
vboxnet0: IPv6 enabled for interface: Success
lo: Configured
docker0: Could not drop address: No such process
vboxnet0: Gained carrier
wlan0: Could not drop address: No such process
eth0: Could not drop address: No such process
eth0: Could not drop address: No such process
eth0: Could not drop address: No such process
vboxnet0: Gained IPv6LL
vboxnet0: Could not set NDisc route or address: Invalid argument
vboxnet0: Failed
[New Thread 0x7ffff6505700 (LWP 1111)]
[Thread 0x7ffff6505700 (LWP 1111) exited]
Assertion 'link->state == LINK_STATE_SETTING_ROUTES' failed at
src/network/networkd-link.c:672, function link_enter_configured().
Aborting.
Program received signal SIGABRT, Aborted.
0x00007ffff6dc6a98 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install
iptables-1.4.21-15.fc23.x86_64 libattr-2.4.47-14.fc23.x86_64
libidn-1.32-1.fc23.x86_64 pcre-8.38-7.fc23.x86_64
Debugging
(gdb) bt
"link->state == LINK_STATE_SETTING_ROUTES", file=0x5555556a34c8
"src/network/networkd-link.c", line=672,
func=0x5555556a56d0 <__PRETTY_FUNCTION__.14850>
"link_enter_configured") at src/basic/log.c:788
src/network/networkd-link.c:672
src/network/networkd-link.c:720
flags=0 '\000', scope=0 '\000', cinfo=0x7fffffffe020) at
src/network/networkd-address.c:344
(rtnl=0x5555556eded0, message=0x55555570ff20, userdata=0x5555556ec590)
at src/network/networkd-manager.c:604
m=0x55555570ff20) at src/libsystemd/sd-netlink/sd-netlink.c:365
at src/libsystemd/sd-netlink/sd-netlink.c:395
ret=0x0) at src/libsystemd/sd-netlink/sd-netlink.c:429
revents=1, userdata=0x5555556eded0) at
src/libsystemd/sd-netlink/sd-netlink.c:723
src/libsystemd/sd-event/sd-event.c:2268
src/libsystemd/sd-event/sd-event.c:2629
timeout=18446744073709551615) at src/libsystemd/sd-event/sd-event.c:2688
bus=0x5555556eeba0, name=0x55555568a2f5 "org.freedesktop.network1",
timeout=30000000,
check_idle=0x55555556adb6 <manager_check_idle>,
userdata=0x5555556ec590) at src/shared/bus-util.c:134
src/network/networkd-manager.c:1130
src/network/networkd.c:127
(gdb) f 3
src/network/networkd-link.c:672
672 assert(link->state == LINK_STATE_SETTING_ROUTES);
(gdb) p link->state
$1 = LINK_STATE_FAILED
We should not be in this state .
even if vboxnet0 failed we went into this state.
vboxnet0: Could not set NDisc route or address: Invalid argument
vboxnet0: Failed
|
|
Fix for #3232.
|
|
Add an option to disable appending DHCP option 3 (Router) to the DHCP
OFFER and ACK packets.
This commit adds the boolean option EmitRouter= for the [DHCPServer]
section in .network files.
Rationale: On embedded devices, it is very useful to have a DHCP server
running on an USB OTG ethernet gadget interface to avoid manual setup on
the client PCs, but it should only serve IP addresses, no route(r)s.
Otherwise, Windows clients experience network connectivity issues, due
to them using the address set in DHCP option 3 as default gateway.
Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
|
|
Makes it consistent with the other branches here.
|
|
|
|
This isn't quite symmetrical to in_addr_from_string() because it also returns
an offset indicating how much of the string was consumed by the matched
pattern. This offset reporting is needed for either of the following use
cases:
* verifying the lack of trailing garbage after such an address
* parsing subsequent data from the same string
|
|
define HEXDIGITS alongside DIGITS, and use it where it's already useful. We'll
use it again shortly when parsing MAC addresses.
|
|
networkd currently silently accepts some strings as MAC addresses that it
probably shouldn't (like "ab:cd:ef:12:34:56:78" and "ab:cd:ef:12:3 4:56").
Add tests to MAC address parsing to ensure that we only accept valid MAC
addresses, and that we accept the three most common forms of MAC address
(colon-delimited hex, IEEE, and Cisco)
Several of these tests currently fail, but another commit in this series will
resolve them.
|
|
|
|
Small networkd cleanup
|
|
core: add io controller support on the unified hierarchy
|
|
|
|
We currently generate log message about unit being started even when
unit was started already and job didn't do anything. This is because job
was requested explicitly and hence became anchor job of the transaction
thus we could not eliminate it. That is fine but, let's not pollute
journal with useless log messages.
$ systemctl start systemd-resolved
$ systemctl start systemd-resolved
$ systemctl start systemd-resolved
Current state:
$ journalctl -u systemd-resolved | grep Started
May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution.
May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution.
May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution.
After patch applied:
$ journalctl -u systemd-resolved | grep Started
May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution.
Fixes #1723
|
|
|
