For a project of mine I need only the mount namespace unshared, which requires the CAP_SYS_ADMIN capability (see namespaces). While it is possible to create a new mount-namespace without capabilities by unsharing the user namespace as well, I would like to avoid that, since this introduces other limitations (e.g. setuid-programs cannot be called from there). I'm thinking about writing a setuid-program which allows unsharing the mountspace for everyone and was wondering, if that is insecure in any way? Currently I cannot think up a scenario where that would be the case. So, what is the rationale behind disallowing unsharing the mountspace for regular users?

  • Because it may allow anyone to create mount namespace with mount points sharing a peer group with some mount point in the original mount namespace. – 炸鱼薯条德里克 Oct 21 '18 at 12:00
  • Could you please you elaborate, how exactly this could be a done? A regular user cannot create mountpoints without appropriate permissions... – spawn Oct 21 '18 at 14:13

I can think of two reasons for the kernel choice.

  1. If / has not been remounted as MNT_SHARED (for example by systemd), then cloning the mount namespace will pin all mounts, including of removable media.
  2. Also, we don't allow unprivileged users to create "unexpected" states, because it has the potential to confuse some setuid program. So this is the safer option, if they have no particular reason to think it would be useful. And they could not think of any significant reason why you would want permission to clone a mount namespace, but not be able to do anything with it. Clearly you have thought of some reason, but even reading your question I was not able to guess what it was :-).
  • What do you mean by "pin" – 炸鱼薯条德里克 Jan 22 at 2:03
  • @炸鱼薯条德里克 keep open, and prevent from unmounting. – sourcejedi Jan 22 at 9:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.