[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 03 Mar 2010 12:50:34 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Jonathan Corbet <corbet@....net>
Cc: hadi@...erus.ca, Daniel Lezcano <dlezcano@...ibm.com>,
Patrick McHardy <kaber@...sh.net>,
Linux Netdev List <netdev@...r.kernel.org>,
containers@...ts.linux-foundation.org,
Netfilter Development Mailinglist
<netfilter-devel@...r.kernel.org>,
Ben Greear <greearb@...delatech.com>,
Serge Hallyn <serue@...ibm.com>,
Matt Helsley <matthltc@...ibm.com>
Subject: Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control. v2
Jonathan Corbet <corbet@....net> writes:
> Quick question:
>
>> +void set_namespace(unsigned long nstype, void *ns)
>> +{
>> + struct task_struct *tsk = current;
>> + struct nsproxy *new_nsproxy;
>> +
>> + new_nsproxy = create_new_namespaces(0, tsk, tsk->fs);
>> + switch(nstype) {
>> + case NSTYPE_NET:
>> + put_net(new_nsproxy->net_ns);
>> + new_nsproxy->net_ns = get_net(ns);
>> + break;
>> + }
>> +
>> + switch_task_namespaces(tsk, new_nsproxy);
>> +}
>
> I assume that, at some future point when more than one namespace type
> is supported, there will be a check to ensure that the type of the given
> namespace matches nstype? I can imagine all kinds of mayhem that could
> result in the case of an accidental (or intentional) mismatch.
>
> Actually, why does setns() require the nstype parameter at all? A
> namespace fd is certainly going to have to know what sort of namespace
> it represents...
But userspace might not know for certain and want to check that it is
getting what it expected. It could be confusing if you think you are
changing your network stack and all of sudden sysv ipc shared memory
was changed instead.
As for the check that nstype is valid that happens earlier in setns.
The plan is to post a patch series with all of the namespace types.
Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists