Email or username:

Password:

Forgot your password?
Top-level
Lennart Poettering

Allowing unprivileged users to just arbitrarily mount file systems is hence a security issue on many levels.

With v256 we are opening this up nonetheless – within limits. Specifically, there's now a small IPC interface where clients can pass an fd to a disk image file to, and get back a mount fd they can attach to a location in the file system. To lock this down securely, a couple of requirements are enforced however.

2 comments
Lennart Poettering

Primarily this means: the DDI *must* come with valid dm-verity data and a signature recognized by the system's keyring (well, if this is missing a polkit authorization is attempted – the user might possibly allow this anyway, if polkit is letting them). And the client must also pass in a user namespace fd (which cannot be the system's main one) to which the mount is restricted.

Lennart Poettering

Various tools (including: systemd-nspawn, systemd-dissect, RootImage= in service files) have been updated to make use of this new IPC service, and thus can now operate without privileges. Or in other words: there's now unprivileged systems-npsawn containers. Yay!)

And that's all for today. See you soon for the 8th installment of this series.

Go Up