[Devel] Re: [patch -mm 09/17] nsproxy: add namespace flags

Cedric Le Goater clg at fr.ibm.com
Thu Dec 7 01:29:28 PST 2006


>>  /*
>> + * namespaces flags
>> + */
>> +#define NS_MNT		0x00000001
>> +#define NS_UTS		0x00000002
>> +#define NS_IPC		0x00000004
>> +#define NS_PID		0x00000008
>> +#define NS_NET		0x00000010
>> +#define NS_USER		0x00000020
>> +#define NS_ALL		(NS_MNT|NS_UTS|NS_IPC|NS_PID|NS_NET|NS_USER)
> 
> hmm, why _another_ set of flags to refer to the 
> namespaces? 

well, because namespaces are a new kind in the kernel

> is the clone()/unshare() set of flags not sufficient 
> for that? 

because we are reaching the limits of the CLONE_ flags.

> if so, shouldn't we switch (or even better change? 
> the unshare() too) to a new set of syscalls?

unshare_ns() is a new syscall and we don't really need a 
clone anyway. nop ? 

we could make the clone flags and namespace flags compatible 
with :

#define NS_MNT		CLONE_NEWNS
#define NS_UTS		CLONE_NEWUTS
#define NS_IPC		CLONE_NEWIPC

that shouldn't be a big issue but we could also 
remove/deprecate :

#define CLONE_NEWNS		0x00020000	/* New namespace group? */
#define CLONE_NEWUTS		0x04000000	/* New utsname group? */
#define CLONE_NEWIPC		0x08000000	/* New ipcs */

to make sure namespaces can not be unshared using 
unshare()

> note: even if they are just for internal purpose
> and will never get exposed to userspace, 

they will. unshare_ns() is a syscall.

> we should think twice before we create just another 
> set of flags, and if we do so, please let us change
> them all, including certain clone flags (and add a
> single compatibility wrapper for the 'old' syscalls)

so you would keep the unshare as is but change the set
of flags its using, making sure the old ones are still 
compatible with the new ones.

something like this :

int sys_unshare(int unshare_flags)
{
	int unshare_ns_flags;

	unshare_ns_flags = convert_flags(unshare_flags);

	return sys_unshare_ns(unshare_ns_flags);
}

?

C.
_______________________________________________
Containers mailing list
Containers at lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers




More information about the Devel mailing list