[9fans] unmount

[9fans] unmount

[arisawa]

Hello 9fans,

current kernel allows unmount even if after rfork m.
this feature makes sandboxing difficult.
can anyone explain this feature is necessary?

Kenji Arisawa

Re: [9fans] unmount

[arisawa]

I said:

> 2015/12/01 12:24、arisawa <arisawa@ar.aichi-u.ac.jp> のメール：
> 
> Hello 9fans,
> 
> current kernel allows unmount even if after rfork m.
> this feature makes sandboxing difficult.
> can anyone explain this feature is necessary?
> 
> Kenji Arisawa

I make a protection for unmounting after rfork -m and now testing.
my idea is: protecting unmount with a single argument.
it seems the following code is working, however I am not sure this is OK.
any comment welcome.

/sys/src/9/port/sysfile.c:

sysunmount(va_list list)
{
	Chan *cmount, *cmounted;
	char *name, *old;

	name = va_arg(list, char*);
	old = va_arg(list, char*);

	/*	a protection for 'unmount' after 'rfork m'
	*	we can reject any unmount, however it might not be user friendly to do so.
	*	more moderate way might be disallowing
	*		unmount mntpoint	# sigle argument
	*	it is ideal though: we disalow unmount dirs that are mounted before rfork m.
	*	probably we need this protection also in regular kernel
	*
	*	print("name=%s old=%s\n",name,old);
	*	the output is, e.g,
	*	name=srv/factorum
	*	old=/mnt
	*	-Kenar-	*/

	if(up->pgrp->noattach && (name == nil)){
		error(Eperm);
		return 0;
	}

Re: [9fans] unmount

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

On 1 December 2015 at 03:24, arisawa <arisawa@ar.aichi-u.ac.jp> wrote:

> current kernel allows unmount even if after rfork m.
> this feature makes sandboxing difficult.
> can anyone explain this feature is necessary?
>

For some applications, similar to ftp or http, I've built a name space
somewhere and then bound that to /.
As you say, that doesn't allow code to run that could unmount that binding.

The approach to encapsulate arbitrary code is similar to newns, perhaps
even using it:
to build a new name space from scratch (#/) that has just what's needed in
it,
prevent new # names from being bound into it using the rfork option, and
then the application can still rearrange
it using bind and unmount but can't escape.

One problem with the existing implementation is that the granularity of
some name space components is
too large. For instance, #p for /proc reveals the names and read-only data,
even if a process can't operate on them;
there's a special little hack to restrict "none", but it's not as clean as
it could be.
Another problem is that the set of # names allowed after RFNOMNT is built
in to the kernel.
There are several ways that could be improved, either through new
interfaces (eg, Roger Peppe's "attach files")
or new services to manage the existing scheme.
I think encapsulation through computable name spaces also ought to be
usable recursively, whereas RFNOMNT is either on or off.

[-- Attachment #2: Type: text/html, Size: 2255 bytes --]

[9fans] unmount

[rog]

while we're on the subject of namespaces, it would be lovely to be
able to temporarily put something in the namespace, and then take it
away, without forking the namespace (i.e.  undo an arbitrary mount or
bind request).

i don't know how, though.

perhaps one could give every mount a unique id (visible in
/proc/$pid/ns, and perhaps as a return from mount) that could then be
named in an unmount request.

perhaps /proc/$pid/mnt could enumerate all the "mounted from"
points in the current name space:

	% bind -v -b '#|' /tmp
	543464
	% unmount /proc/$pid/mnt/543464 /dev

just a thought.

Re: [9fans] unmount

[rob pike, esq.]

every mount has a 'mountid' and this is actually returned by the
mount system call.  never came up with a good way to use them,
but it would be trivial to make an unmount system call that used
the id.

-rob