Re: /etc/mtab and per-process namespaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dr. Greg Wettstein <[email protected]> wrote:
> On Oct 13,  7:10pm, Mike Waychison wrote:
> } Subject: Re: /etc/mtab and per-process namespaces

> I've been pondering the best way to take on the mount problem.
> Current mount binaries seem to fall back to /proc/mounts if /etc/mtab
> is not present.  All bets are off of course if the mount binary is
> used for the bind mount since a new /etc/mtab is created.
> 
> I'm willing to whack on the mount binary a bit as part of this.  The
> obvious solution is to teach mount to act differently if it is running
> in a private namespace.  If anybody knows of a good way to detect this
> I would be interested in knowing that.  In newns (the namespace sudo
> tool) I'm setting an environment variable for mount to detect on but a
> system level approach would be more generic.

- If named namespaces are to be implemented, you could check for a set
  namespace ID. (You could also get rid of the persistent-namespace-daemon.)

- If secure user mounts are implemented, missing privileges will be hint.
  Privileged mounts will require a global configuration where a flag can
  be set. (BTW: You'll also want to disable user mounts in global namespaces
  to catch errors, abuse and exploits)

- Until any of these is implemented, users will run in a private namespace,
  so UID != EUID will indicate a private namespace. Unfortunately this is
  not secure, but:

- If the proc/mounts information is extended as described below, a different
  behaviour wouldn't make sense anymore, would it?

> The other problem is the information exported in /proc/mounts.  It
> would seem problematic to modify its format but in order to serve as a
> useful source of information for a modified mount binary it would need
> to contain mount option information.  Since this is definitely process
> specific information it would seem to call for something in /proc
> rather than /sysfs.  Do we need a new pseudo-file?

- The file format is broken for whitespace in filenames, so changing the
  format in these cases by adding quoting won't actually break anything.

- The userspace options (loop device etc) can be encoded in the mount
  options field, e.g.
  'rw,mount=lo:"/home/Arthur Dent/iso":/dev/loop/42;ns=public,async'.

So if you _want_ to keep the format, you can IMHO do so. Maybe you can
think of something better, who knows? We'll need to upgrade the tools
to use non-broken semantics anyway, so as long as you keep the old file
around, this should be no real problem.

-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux