On Tue, Aug 20, 2019 at 02:51:32PM +0200, Karel Zak wrote: > On Thu, Aug 15, 2019 at 12:54:45PM +0200, Patrick Steinhardt wrote: > > In order to execute commands with the least-possible privileges, it may > > be desirable to provide them with a trimmed down filesystem view. > > unshare naturally provides the ability to create mount namespaces, but > > it doesn't yet offer much in preparing these. For now, a combination of > > unshare and nsenter is required to prepare culled filesystems views, > > which is kind of unwieldy. > > > > To remedy that, this implements a new option "--mount-fs". As > > parameters, one may specify a source filesystem, the destination where > > this filesystem shall be mounted, the type of filesystem as well as a > > set of options. unshare will then mount it using libmount right before > > performing `chroot`, `chdir` and the subsequent `execve`, which allows > > for preparing the `chroot` environment without using nsenter at all. > > > > The above is useful in several different cases, for example when one > > wants to execute the process in a read-only environment or execute it > > with a reduced view of the filesystem. > > I understand your point of view, but it's a way how unshare(1) will > slowly grow from simple one-purpose tool to complex container/namespace > setup tool ;-) I do not have any strong opinion about it. Maybe your > --mount-fs is still so basic that we can merge it into unshare(1) > > Sounds like we need a discussion about it to gather more opinions :-) > (CC to Eric). Sounds fair to me. The main motivation I have is that I want to use unshare(1) as part of runit(8) to spawn supervised processes in their own namespaces. And using multiple steps to set up namespaces and spawn the executable makes things a lot more error prone. > Note that the latest mount(8) has --namespace option, so you can mount > filesystems in the another namespace although the namespace does not > contain mount command and necessary libs. That would require me to set up persistent namespaces first, though, while unshare(1) allows me to use transient ones that disappear as soon as the executable exits. > And note that for systemd based distros there is systemd-nspawn which > provides many many features (include IPC, hostname, TZ, private users, > ...). Yeah, I know of that one, but as I'm using runit(8) as PID1 systemd-nspawn(1) is not a viable route, at least as far as I know. I'm definitely inspired by that tool, though, and would love to have something similar that is completely agnostic of what init system is running. > > +.B # unshare > > +.B --mount-fs=none:/tmp:tmpfs > > +.B --mount-fs=/bin:/tmp/bin:none:bind,ro,X-mount.mkdir > > +.B --mount-fs=/lib:/tmp/lib:none:bind,ro,X-mount.mkdir > > +.B --mount-fs=/usr/lib:/tmp/usr/lib:none:bind,ro,X-mount.mkdir > > +.B --root=/tmp /bin/ls / > > The libmount also allows to mount all filesystem according to mount > table stored in a file, so I can imagine --fstab option ;-) I thought about exposing parsing of fstab-style lines from libmount. But I'd definitely be happy to implement an "--fstab" option instead, that would work perfectly fine for my own usecase and probably simplify code by quite a bit. Regards Patrick
Attachment:
signature.asc
Description: PGP signature
