| 2018-12-04 11:48:24 |
Silvan Kaiser |
description |
With different linux distros the systemd-run based mount of a Quobyte volume can fail. This is connected to the --user option causing issues with privilege escalation. Log example:
Mar 19 09:09:27 manualnovaci nova-compute[20516]: ERROR nova.compute.manager [instance: 6ffe17b6-9706-48d2-9ca5-73a670889a19] ProcessExecutionError: Unexpected error while running command.
Mar 19 09:09:27 manualnovaci nova-compute[20516]: ERROR nova.compute.manager [instance: 6ffe17b6-9706-48d2-9ca5-73a670889a19] Command: systemd-run --scope --user mount.quobyte --disable-xattrs 78.46.57.153:7861/
Mar 19 09:09:27 manualnovaci nova-compute[20516]: ERROR nova.compute.manager [instance: 6ffe17b6-9706-48d2-9ca5-73a670889a19] Exit code: 1
Mar 19 09:09:27 manualnovaci nova-compute[20516]: ERROR nova.compute.manager [instance: 6ffe17b6-9706-48d2-9ca5-73a670889a19] Stdout: u''
Mar 19 09:09:27 manualnovaci nova-compute[20516]: ERROR nova.compute.manager [instance: 6ffe17b6-9706-48d2-9ca5-73a670889a19] Stderr: u'Failed to create bus connection: No such file or directory\n'
Besides this the current systemd check is erroneous due to whitespace in path. |
I'm rewriting the bug report as the original report was not accurate enough (still, the original report can be seen further down in this entry).
Updated bug report:
The Quobyte Nova driver checks for the presence of systemd in order to run mounts via systemd-run if available. However the systemd mount execution is broken in several aspects:
a) systemd detection has an additional whitespace in the path comparison, causing all instances to run without systemd
b) The systemd-run call is broken for CentOS as so far the currently installed systemd version on centos is 219 which does not support the '--user' flag
c) systemd had a bug for several releases that caused "systemctl-run --scope --user" calls to fail on e.g. Ubuntu Xenial (uses v229, fix in systemd was released in v238 according to [1]).
d) When run via processutils the systemd based mount command is executed in a context that does not allow using the "--user" flag resulting in an error as shown in the original bug report. This looks similar to executing systemd-run with --user option as user root.
For these reasons (b to d) the systemd mount variant in the driver needs to be run as root and the detection (a) to be fixed.
[1] https://github.com/systemd/systemd/blob/master/NEWS
Original bug report:
With different linux distros the systemd-run based mount of a Quobyte volume can fail. This is connected to the --user option causing issues with privilege escalation. Log example:
Mar 19 09:09:27 manualnovaci nova-compute[20516]: ERROR nova.compute.manager [instance: 6ffe17b6-9706-48d2-9ca5-73a670889a19] ProcessExecutionError: Unexpected error while running command.
Mar 19 09:09:27 manualnovaci nova-compute[20516]: ERROR nova.compute.manager [instance: 6ffe17b6-9706-48d2-9ca5-73a670889a19] Command: systemd-run --scope --user mount.quobyte --disable-xattrs 78.46.57.153:7861/
Mar 19 09:09:27 manualnovaci nova-compute[20516]: ERROR nova.compute.manager [instance: 6ffe17b6-9706-48d2-9ca5-73a670889a19] Exit code: 1
Mar 19 09:09:27 manualnovaci nova-compute[20516]: ERROR nova.compute.manager [instance: 6ffe17b6-9706-48d2-9ca5-73a670889a19] Stdout: u''
Mar 19 09:09:27 manualnovaci nova-compute[20516]: ERROR nova.compute.manager [instance: 6ffe17b6-9706-48d2-9ca5-73a670889a19] Stderr: u'Failed to create bus connection: No such file or directory\n'
Besides this the current systemd check is erroneous due to whitespace in path. |
|
