[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