systemd/test/test-execute/exec-readonlypaths-with-bindpaths.service

[Unit]
Description=Test for ReadOnlyPaths=

[Service]
ReadOnlyPaths=/etc -/i-dont-exist /usr
BindPaths=/etc:/tmp/etc2
ExecStart=/bin/sh -x -c 'test ! -w /etc && test ! -w /usr && test ! -e /i-dont-exist && test -w /var'
Type=oneshot
test: add test for ReadOnlyPaths= with RuntimeDirectory= 2017-10-28 09:35:19 +03:00			`[Unit]`
			`Description=Test for ReadOnlyPaths=`

			`[Service]`
			`ReadOnlyPaths=/etc -/i-dont-exist /usr`
core: be more lenient when checking whether sandboxing is necessary In some containers unshare() is made unavailable entirely. Let's deal with this that more gracefully and disable our sandboxing of services then, so that we work in a container, under the assumption the container manager is then responsible for sandboxing if we can't do it ourselves. Previously, we'd insist on sandboxing as soon as any form of BindPath= is used. With this change we only insist on it if we have a setting like that where source and destination differ, i.e. there's a mapping established that actually rearranges things, and thus would result in systematically different behaviour if skipped (as opposed to mappings that just make stuff read-only/writable that otherwise arent'). (Let's also update a test that intended to test for this behaviour with a more specific configuration that still triggers the behaviour with this change in place) Fixes: #13955 (For testing purposes unshare() can easily be blocked with systemd-nspawn --system-call-filter=~unshare.) 2019-11-20 14:23:17 +03:00			`BindPaths=/etc:/tmp/etc2`
test: add test for ReadOnlyPaths= with RuntimeDirectory= 2017-10-28 09:35:19 +03:00			`ExecStart=/bin/sh -x -c 'test ! -w /etc && test ! -w /usr && test ! -e /i-dont-exist && test -w /var'`
			`Type=oneshot`