Hello Tycho,
On Thu, 25 Oct 2018 at 14:51, Tycho Kirchner <tychokirchner@xxxxxxx> wrote:
>
> Update the mount_namespaces(7) with a mention that unsharing the
> mountspace require the CAP_SYS_ADMIN-capability.
But this is already fairly clearly stated in the unshare(2) page (and
is also mentioned in namespaces(7)). It seems to me unnecessary to
repeat the info in mount_namespaces(7), but then I do not read this
page as a new user. Tell me, did you miss the info in unshare(2), or
do you feel that nevertheless the info should be repeated?
> If possible, please
> also add a justification because I know of several people who would like
> to understand that.
I've tried to capture this by adding a few words to the namespaces(7) page;
Creation of new namespaces using clone(2) and unshare(2) in most
cases requires the CAP_SYS_ADMIN capability, **since, in the new
namespace, the creator will have the power to change global
resources that are visible to other processes that are subse‐
quently created in, or join the namespace**.
> (In fact I'm about to write a setuid-program which allows unsharing the
> mountspace for everyone and was wondering, if that is insecure in any
> way? What is the rationale behind disallowing unsharing the mountspace
> for regular users? Note that I know that doing so is possible by also
> unsharing the usernamespace, but this introduces other limitations [e.g.
> setuid-programs cannot be called from there]).
A while back, I added some text to the capabilities(7) manual page
(http://man7.org/linux/man-pages/man7/capabilities.7.html) that may
help you better understand what's going on here. See the subsections
"File capability mask versioning" and "Namespaced file capabilities".
> Thank you very much, also for the valuable work you have done so far.
You're welcome. Unfortunately, my available time is quite limited these days...
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
