[prev in list] [next in list] [prev in thread] [next in thread]
List: util-linux-ng
Subject: Re: [PATCH] unshare: allow setting up filesystems in the mount namespace
From: ebiederm () xmission ! com (Eric W ! Biederman)
Date: 2019-08-20 15:41:59
Message-ID: 87ef1fj12w.fsf () xmission ! com
[Download RAW message or body]
Patrick Steinhardt <ps@pks.im> writes:
> 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.
My vision of unshare is a simple command line debugging tool. It let's
you get at the raw functionality. It might be useful in scripts but it
doesn't provide a nice environment. The secondary purpose I see for
unshare is as a small example that shows how easy it is to use all
of the functionality.
At least for me unshare is what I turn to do all of the steps manually,
and keeping it simple and focused is a major benefit to that cause.
>> 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.
The tricky part of all of this appears to be permission management. As
soon as you change your uids and/or exec you are in trouble. As that
will cause you to loose CAP_SYS_ADMIN (unless you are running a service
as root).
My sense is that it would be easiest to write a little tool that does
what you need to run services. Possibly as a PAM plugin. I know
originally that is how the unshare system call was expected to be used,
and unshare fits in well with that model. The example of a PAM plugin
is that potentially runit and sshd could be convinced to setup the
environment for you when you start them.
In fact I think there might already be a PAM plugin for a private /tmp.
Now maybe util-linux is the place for that tool to live. But I don't
think the unshare command itself is where we want to put the
functionality.
Eric
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic