Now that we have app sets in the interfaces repo, keep a pointer to them in ConnectedPlug/Slot types. Use this to build label expressions in the interfaces.
* many: add a pointer to a SnapAppSet into Connected(Plug|Slot) to that interfaces can build a complete label expression, including component hooks
* interfaces: update doc comments on ConnectedPlug/Slot.AppSet
* interfaces: remove TODO that has been addressed
* interfaces: use app set pointer for instance name check
* snap: add Runnable type that represents the runnable parts of a snap
* interfaces, o/ifacestate: use snap.Runnable rather than interfaces.Runnable
* interfaces, i/builtin, o/ifacestate: panic on failed invariant check in NewConnectedPlug/Slot
* interfaces: add methods to app set for getting runnables that can connect to plug/slot
* interfaces: build label expressions using runnables
* interfaces: doc comment for SlotRunnables
* interfaces: implement Slot/PlugRunnables with shared helper
* interfaces: log and skip security tags that do not match expected pattern
* snap, interfaces: move runnable constructors to methods on AppInfo and HookInfo
* interfaces: refactor to allow labelExpr to operate directly on a ConnectedPlug/Slot
* snap: move around Runnable methods
* features,i/{apparmor,builtin}: include prompt prefix in home interface
If prompting is supported and enabled, include the prompt prefix in
AppArmor rules for the home interface, which will cause AppArmor to send
a prompt when accessing any file in $HOME.
In the future, if other interfaces include the ###PROMPT### prefix in
their rule snippets, this will also be handled accordingly.
At the moment, the status of prompting support is checked whenever the
AppArmor backend prepares profiles. This is okay, since AppArmor support
for prompting depends on kernel and parser features, which are only
probed once after snapd starts. However, to ensure that the same
supported value is used even if that were not the case, and in case we
wish to only use the prompt prefix for some snaps or interfaces, we may
wish to embed whether to use the prompt prefix in the AppArmor
Specification instead.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* features: adjust unsupported messages when checking apparmor features errors
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces: add prompting status to system key
Include whether prompting is supported and enabled as a single field in
the system key. This way, if `(supported && enabled)` changes, security
profiles will be regenerated when snapd starts up.
Currently, prompting support only changes when the AppArmor kernel or
parser features change, and profile regeneration is the only other place
where it is checked whether AppArmor prompting is supported and enabled.
Thus, including whether prompting is supported and enabled in the system
key ensures that security profiles are regenerated when necessary during
snapd startup, and only when necessary (e.g. not if support changed but
prompting flag remained disabled nor if flag changed but prompting
remained unsupported).
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* o/c/configcore: restart snapd when prompting value changes
When the prompting flag changes and the result entails that security
profiles should be regenerated, restart snapd to do so.
This is required iff prompting is supported and the experimental
apparmor-prompting flag changes -- if prompting is not supported,
prompting can't be used, so no need to regenerate profiles. Importantly,
prompting support is based entirely on the available AppArmor kernel and
parser features, and these are only probed once during snapd startup, so
prompting support cannot change (under the current implementation)
except when snapd restarts.
Since `(supported && enabled)` is part of the system key, and a restart
is only triggered if prompting is supported and the flag value changes
(which is equivalent to `(supported && enabled)`, since the supported
value cannot change while snapd is running), restarting after the flag
has changed causes the system key to be different, and thus to trigger a
security profile regeneration, as desired.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces,o/ifacestate: set prompting in apparmor spec
Rather than checking whether AppArmor prompting is supported and enabled
whenever the AppArmor backend is processing a snippet, instead include
that precomputed value in the Specification itself, and place it there
via `buildConfinementOptions`. This way, any spec created with the same
`confinementOptions` will make the same decision as to whether to
include prompt prefixes on relevant rules.
Currently, `buildConfinementOptions` simply checks whether prompting is
supported and enabled via the methods on `features.AppArmorPrompting`,
but ideally, this value would be looked up from either the system key
or by checking whether the prompting listener is running. It remains to
be seen how the value computed as part of the system key can be
guaranteed to be the same as that used elsewhere, either in
`buildConfinementOptions` or when deciding whether to start the
listener.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* o/c/configcore: request snapd restart whenever prompting flag changes
Previously, a snapd restart was only requested when the status of the
"apparmor-prompting" experimental feature flag changed and prompting was
supported. However, since prompting support is dependent on AppArmor
kernel and parser features which are probed only once during startup,
and systems which do not use vendored AppArmor may have had an update to
the system AppArmor package which newly supports AppArmor prompting, it
is safer to request a restart of snapd to re-check for prompting
support.
This way, if one is enabling prompting for the first time on a system
without prompting support, they can have snapd installed, update their
kernel or apparmor installation to support prompting, and then set the
prompting flag to enable prompting without needing to manually restart
snapd.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces: support optional trailing space after ###PROMPT###
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
i/apparmor: move promptReplacer definition to before its use
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* tests: add test of restart behavior when setting experimental.apparmor-prompting
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* tests: refactor prompting test to reset failed count and safely check for restarts
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
tests: add shellcheck exception for apparmor prompting flag restart test
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* tests: check that snapd PID != 0 and use snap changes to wait for feature change to complete
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* tests: check for start-limit-hit before calling reset-failed
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* tests: add ubuntu core to apparmor prompting flag restart test
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* tests: check apparmor-prompting value after setting it unchanged
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* Revert "tests: check for start-limit-hit before calling reset-failed"
This reverts commit bea68516c3287fa44d6718f0794484746ae99ac5.
* tests: check systemd start-limit-hit when apparmor-prompting flag changed
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* o/configstate/configcore: add unit tests for doExperimentalApparmorPromptingDaemonRestart
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* i/builtin: add missing prompt prefix and adjust test
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* i/apparmor: add test for prompt prefix substitution
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* many: pass prompting value into system key functions
As such, we now precompute whether prompting is supported and enabled in
`InterfaceManager.StartUp()`, store it in the `InterfaceManager`
instance, and pass it into the call to `WriteSystemKey()`.
Additionally, we make `buildConfinementOptions` a method of
`InterfaceManager`, thus eliminating the need to check within the system
key functions whether prompting is supported and enabled.
However, there remains a problem that `snap run` calls
`SystemKeyMismatch()`, which previously invoked
`apparmor.ParserFeatures()` via `AppArmorPrompting.IsSupported()`, and
now calls `AppArmorPrompting.IsSupported()` directly and passes the
result into `SystemKeyMismatch()`. In either case, we really want this
to be avoided if at all possible, since `snap run` does not have access
to the cached value from the `InterfaceManager`, and thus must invoke
the `apparmor_parser` binary to check parser features whenever we want
to run any snap.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* many: don't probe parser features when checking system key mismatch
Since `snap run` calls `SystemKeyMismatch()`, we want to avoid needing
to call `AppArmorPrompting.IsSupported()` if at all possible, since this
calls `apparmor.ParserFeatures()`, which executes the `apparmor_parser`
binary. We can and should call `AppArmorPrompting.IsSupported()` when
writing the system key, but not when checking for a mismatch.
The system key written to disk should correctly hold the list of kernel
and parser features, the parser mtime, and whether or not prompting was
previously supported and enabled. We can check whether apparmor parser
features have changed by checking the parser mtime, without needing to
probe parser features -- this optimization is already used by
`SystemKeyMismatch()`. If we knew whether prompting was previously
supported (regardless of whether it was enabled), then so long as the
parser and kernel features are unchanged, we know that prompting support
is also unchanged.
Thus, if we add a second prompting-related field to the system key, this
one storing whether prompting is supported (ignoring enabled), we can
check if prompting support is unchanged without needing to call
`AppArmorPrompting.IsSupported()`.
Furthermore, `SystemKeyMismatch()` is the function in question, and if
there is any mismatch detected, it should return such as soon as
possible, regardless of what the mismatch is. Therefore, if we know that
either kernel or parser features have changed, then we can immediately
return that there is a mismatch, and we don't need to check whether
those feature changes affect prompting support.
Therefore, the new cases which we must worry about when checking for a
system key mismatch are the following, when all other system key fields
are unchanged (note that prompting must be supported in order to be
supported&&enabled):
1. supported: F, supported&&enabled: F, newFlag: F, mismatch: F
2. supported: F, supported&&enabled: F, newFlag: T, mismatch: F
3. supported: T, supported&&enabled: F, newFlag: F, mismatch: F
4. supported: T, supported&&enabled: F, newFlag: T, mismatch: T
5. supported: T, supported&&enabled: T, newFlag: F, mismatch: T
6. supported: T, supported&&enabled: T, newFlag: T, mismatch: F
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces: fix test string formatting
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* o/configstate/configcore: adjust prompting-related comments
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* tests: increase prompting check_snapd_restarted timeout and add systemd show
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* tests: reset start limit when checking if snapd restarted after prompting change
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* many: add system key extra data to hold prompting enabled status
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* many: only store one apparmor prompting value in system key
When checking for a system key mismatch, use the stored AppArmor
parser features from the system key on disk (along with the kernel
features from the newly-generated key) to check whether prompting is
supported, and AND that with the `AppArmorPrompting` value passed in
with the `SystemKeyExtraData`. If the kernel or parser features have
changed, the system key will be a mismatch anyway, so it is perfectly
safe to use the existing parser features to check for prompting support.
As such, the functions to check for prompting support have been moved
from `features` to `sandbox/apparmor`, and the support check has been
separated from the call to get `ParserFeatures()` and
`KernelFeatures()`, so that the values from the system key can be passed
in instead of invoking those functions.
Using the system key's stored parser and kernel features, there is no
need to save whether prompting is supported as part of the system key,
simplifying the key and the logic used to set the prompting value.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* tests: explicitly install jq in apparmor-prompting-flag-restart test
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* many: consolidate checks for apparmor prompting support
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces,s/apparmor: use features struct when checking prompting support
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* tests: improve logging in apparmor-prompting-flag-restart test
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* tests: fix prompting flag restart test on core18
For some reason, when snapd fails due to start-limit-hit on core18, the
snapd.failure.service starts and acquires the state lock, thus
preventing snapd from successfully becoming "active" again and leaving
it retrying at "activating". It is unclear why this happens on core18
and not elsewhere.
As a fix, when resetting the start limit, stop snapd.failure.service
manually to ensure that snapd can successfully start.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
---------
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
Snapd from the snap generate udev rules that executes snap-device-helper
from the host. In cases when the snap is newer than the package, the
new command line is rejected by the old snap-device-helper from the
package. Because the new snap-device-helper accepts old command-line,
but just ignores the extra parameters, it is safer for now to generate
rules with the old command line.
* interfaces/udev: add non-strict flag to snap cgroup device file
Add a non-strict=true flag to the snap's cgroup device file, to inform
snap-confine that the snap was indeed installed in a non-strict confinement mode
(eg. devmode, or classic). This supplements an earlier mechanism in which snapd
would not generate any rules tagging devices for a specific snap and can be used
as an explicit indicator to avoid mandatory device cgroup even when using bare
or core24 and later bases (as well as custom base snaps).
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: account for non-strict confinement when setting up device cgroup
Snaps may be installed in a non-strict confinement mode. In which case, expect
an explicit non-strict=true in the per snap /var/lib/snapd/cgroup/snap.*.file.
This replaces an earlier mechanism of implicit non-strict confinement when no
devices are assigned to the snap.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-required-or-optional: update to check non-strict confinement
Update the test to check that --devmode results in a non-strict confinement
device cgroup setup.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
---------
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
The udev backend was not preseed aware and would always call udev reload, even
before introducing #13642 and the errors were masked. Check if the backend is
running in preseed mode and do not call udev at all.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* dirs: add directory location for storing cgroup policy related flags
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: introduce cgroup policy flag for self managed device cgroup
Some snaps, due to their interfaces, are allowed to self manage the device
cgroup. In this case, the assumption was to not emit any rules at all, and
instead rely on the implicit behavior that no rules means no matching devices
and hence no device cgroup filtering. However, with introduction of a device
cgroup by default for all snaps on core24 onward, regardless of any assigned
devices, we need a separate source of information to indicate that a snap can do
self management.
The patch introduces a policy flags under /var/lib/snapd/cgroup, named
snap.<name>.device, eg.
/var/lib/snapd/cgroup/snap.docker.device, which provides a hints for
snap-confine to not set up a device cgroup filtering for apps.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: support snaps which self-manage device cgroup
Support for snaps for which policy explicitly states that the device cgroup is
self-managed. The typical use case is container like technologies. In such
scenario, there will be a device cgroup configuration file at a known location
which got generated by snapd whenever the relevant interface state changed.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-self-manage: spread test
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: drop base from bases exempt from mandatory device cgroup
We have confirmed that there are no snaps which (ab)use system files and use
bare base to obtain access to devices. As such, the bare base can be dropped
form the list of bases exempt from mandatory device cgroup.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: remove snap devices file when removing the snap
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: consistent use of fs.ErrNotExist
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: leave comments
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: tweak return path
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: improve managed device cgroup unit tests, verify calls to udevadm
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* NEWS: leave a note about mandatory device cgroup
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-self-manage: tweak comments
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: always write the device file
Always write the device file which serves as a synchronization point between
snap-confine and the snapd udev backend.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/libsnap-confine-private: add helper for waiting for a file to show up
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: make cgroup device file mandatory
Make the per-snap /var/lib/snapd/cgroup/snap.*.device file mandatory, such that
it can be used as a synchronization point between snapd calling Setup() of
relevant security backends and the execution path in snap-confine.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-mgmt: do cleanup of /var/lib/snapd/cgroup
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* packaging: declare /var/lib/snapd/cgroup
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: use the file wait helper
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* packaging: create cgroup directory
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-self-manage: update file check
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-required-or-optional: update test to verify device file
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: refactor reloading
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: move device cgroup mode selection to a helper
Extract device cgroup mode selection into a helper function.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
---------
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Add device-cgroup-v2 sandbox feature flag which was forgotten when we landed
cgroup v2 device filtering support.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces: introduce SnapAppSet and forward one to the security backends
* snap: implement methods on snap.Info for getting apps and hooks for slots and plugs
This will enable us to remove the Hooks fields from the SlotInfo and
PlugInfo structs.
* interfaces: implement methods on SnapAppSet in terms of methods on snap.Info
* snap, interfaces: replace usage of {Plug,Slot}Info.SecurityTags with methods on SnapAppSet
* i/builtin: replace slotAppLabelExpr and plugAppLabelExpr with corresponding methods on SnapAppSet
* snap, o/snapstate, interfaces: remove Hooks field on snap.PlugInfo and snap.SlotInfo
* builtin, interfaces: fix tests that use Specification that now have a SnapAppSet
* snap: add tests for new methods on Info
* interfaces, i/builtin: port over some tests for SnapAppSet methods {Plug,Slot}LabelExpression
* interfaces: test PlugSecurityTags and SlotSecurityTags methods
* interfaces: add doc comments to SnapAppSet and methods
* i/builtin: remove ported over tests
* interfaces, many: require that SnapAppSet methods for getting security tags are called with plug/slot that comes from correct snap
Many tests did not properly adhere to this requirment, so they had to be
modifed to modify this rule.
Additionally, a hack was inroduced in the methods for getting label
expressions on the SnapAppSet. If a plug/slot did not originate from the
same snap that the SnapAppSet was created from, then we will use the
snap.Info that the plug/slot carries in the method instead. This will
fail to work once component hooks are introduced, so this will need to
be resolved by then.
* interfaces: test fallback for using LabelExpr methods with mismatch plug/slot
* snap: correct placement of TODOs to preserve doc comments
* snap: add doc comments for Plug/Slot.Unscoped
* interfaces: test for using SecurityTagsForPlug and SecurityTagsForSlot with wrong snap
* interfaces: tweak error messages in SnapAppSet SecurityTags methods
* i/builtin: fix missed conflict
* i/apparmor: add doc comment to Specification.appSet
* snap: fix doc coment on PlugInfo.Unscoped
Module loading generates event for devpath /module/<nameofmodule>.
Some modules and devices have the same KERNEL name. For example
rfkill. We need to ignore module insertions. Otherwise we get
error message when trying to run snap-device-helper.
Go 1.19 includes some changes to gofmt which intend to make lists and
heading clearer when rendered (https://go.dev/doc/go1.19). This commit
is the result of running the new gofmt and manually fixing some of it.
This was necessary because the new gofmt assumed lines beginning w/ tabs
to start lists or examples. While this is often true in our codebase,
we occasionally also use tabs to indent the lines after a TODO or FIXME
prefix or in yaml (e.g., excerpts of a snap.yaml). This meant that a lot of the
reformatted comments were broken and had to be fixed manually.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
The old code would run unnecessary `udevadm trigger` commands in a
couple of situations:
1. If a subsystem other than "input" was specified, the trigger for it
would be run twice: once because of the unconditional call to
`udevadm --subsystem-nomatch=input`, and once because of the call to
`udevadm --subsystem-match=<subsystem>`.
2. If both "input" and "input/keys" are part of the subsystem list,
there's no need to run a trigger specific to the keys: running the
trigger for the whole "input" subsystem is enough.
This commit replaces the use of "sanity" with more inclusive
naming. When "sanity" is used in a more general sense either
"validity" or "quick" is used.
* interfaces/microstack-support: set controlsDeviceCgroup to true
This will prevent us from generating any udev rules which in turn should
entirely disable the enforcement of the device cgroup for processes in the
snap.
This is justified by the snap already managing cgroups of its containers and
VM's with the Delegate=true setting in serviceSnippets.
See also LP bug: https://bugs.launchpad.net/snapd/+bug/1892895 which is
partially addressed by this commit, specifically for the microstack snap which
uses the microstack-support interface.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests: add spread test for microstack cgroup delegation
* tests/main/interfaces-microstack-support: use snap restart
This fixes the test by making it fail on master without the change to use
controlsDeviceCgroup, but passes in the branch enabling that for the interface.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests: fix microstack-support test for cgroup v2
* i/b/microstack_support: add comment about delegation
* tests/microstack: make the service more verbose
Making the service more verbose might help debugging; these lines will
end up in journald.
* interfaces/udev/spec.go: leave TODO about cgroup interaction w/ Delegate=true
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Co-authored-by: Alberto Mardegan <alberto.mardegan@canonical.com>
* interfaces/udev: fix installing snaps inside lxd in 21.10
In 21.10 a snap install inside an LXD container can trigger the an
error from `udevadm trigger`. This was reported in
https://github.com/lxc/lxd/issues/9526 and the advise from the
LXD folks is to ignore `udevadm trigger` exit-code errors. Only
systemd 248 started to report errors so they have always been
there but where just never reported before.
Plus as Ian put it so eloquently: We aren't really in the business
of reacting to any udevadm errors here, so there isn't really anything
we could do about errors that do crop up when we run this.
We could maybe try and detect that we are inside a container, and only
ignore udevadm errors in that case rather than always ignore udevadm
errors, but I'm not convinced that these new changes to systemd in
21.10 and newer which make udevadm return an error code won't also
some day make native hosts running new udevadm return an error code
"by default" on some folks' system in which case we would probably
have no option except to just remove that check for being in a
container anyways.
* udev: rework error handling (thanks to Pawel)
* udev: add some better comments (thanks to Maciej)
The snap-device-helper is located under $libexecdir which is /usr/lib/snapd on
some distros, but /usr/libexec/snapd on others (Fedora, recent openSUSE
Tumbleweed).
The commands triggered by rules are executed by udevd which runs in the same
mount ns as pid 1, which is the rootfs of a specific distribution.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
