[lxc-devel] per-session network namespace question

[Wilhelm Meier]

Daniel Lezcano schrieb:
> Wilhelm Meier wrote:
>>
>>
>> Daniel Lezcano schrieb:
>>> Wilhelm Meier wrote:
>>>> Hi,
>>>>
>>>> Daniel Lezcano schrieb:
>>>>> Wilhelm Meier wrote:
>>>>>> Hi,
>>>>>>   
>>>>>
>>>>> Hi Wilheim,
>>>>>
>>>>> I am not sure I understand your question. Can you elaborate a 
>>>>> little bit ?
>>>>
>>>> ok:
>>>> I would like to compare the desired function with pam_namespace: 
>>>> using pam_namespace (or fs-namespaces in general) one could setup a 
>>>> new fs-namespace if a user logs into the system. That is, mount into 
>>>> this namespace are not visible from outside this namespace. This is 
>>>> especially useful for multiseat-systems, where every user makes his 
>>>> own mounts for e.g. local devices.
>>>>
>>>> So, what I'm looking for is the ability to do the same with 
>>>> network-namespaces. Imagine th use-case of a ssh-tunnel to a remote 
>>>> machine: the local end of the tunnel is visible for all users of the 
>>>> system, although authenticated only for the user who created it.
>>>> It would be nice, if one can setup a new network-namespace for each 
>>>> user session, so that the above ssh-tunnel local end is only visible 
>>>> to the processes in this network-namespace.
>>>
>>> Ah, ok. Got it :)
>>> Is's a nice idea.
>>>> As described above I don't want to start a full container with a 
>>>> sshd inside. I'm interested in restricting the access to a listening 
>>>> port and the visibilty of this port a group of processes. These 
>>>> processes are the descendents of the login/kdm-process.
>>>
>>> Hmm, the lxc tools isolates a lot of things by default, pid, ipc, 
>>> utsname and mount points. The network is optional and configurable 
>>> via a configuration file.
>>>
>>> There is no way to use only the network namespace with the lxc tools 
>>> except by using the lxc-unshare but this one does not configure the 
>>> network for you.
>>
>> Well, with the help of the lxc-tools source it should be possible to 
>> code a pam-module for this purpose.
> Yes, especially the netlink.[ch] + network.[ch] should be useful ;)
> 
> Be aware the network namespace isolates af_unix socket 

Does this mean that a process in the new network namespace can't 
reach/connect a socket that was created in another namespace but visible 
in the filesystem. An important example would be the dbus-socket in 
/var/run/dbus for the system-dbus instance.

If this is the case is there a way to circumvent the problem (for dbus: 
afaik one can create an additional dbus listen address, so it should be 
possible to setup a tcp-listen-address on the vethx interface in the 
root network-namespace)

and creates a new
> loopback instance, hence you won't be able to use syslog, neither any 
> rpc applications (eg. nfs, mountd, ...).
> 
>>
>> I admit that I hadn't the time to do some testing with the lxc-tools, 
>> but one question still remains:
>>
>> Imagine the case of a login/kdm: they fork a new process to perform 
>> the login, that is this process uses the pam-stack. If we develop a 
>> pam-module for network-namespace setup, this module can setup and 
>> configure a veth-pair and then unshare the process from the original 
>> network-namespace. But how can we then (after the unshare) move the 
>> vethx from the original ns to the new ns? After the unshare the 
>> veth-pair is unvisible to the login-process that has already called 
>> the pam-module.
> Correct.
>> I can imagine a helper-process started before the unshare which waits 
>> for the unshare to complete (some sort of trigger-mechnism neccessary) 
>> and then does the veth-move. 
> Yes, right. When I played with the network namespace using the unshare 
> instead of the clone, I used this approach, with a sync pipe, that works 
> well.
> 
>> Or is there a possibility the mark the veth-dev as to be moved when 
>> the unshared-call happens?
> This mechanism was not implemented because that can be done in userspace 
> with a simple function doing what you described right before.
> 
> eg :  unshare_network(char *netdev[], size_t howmany);
> 
>> Thanks for yout comments!
> You are welcome :)
> 
> Thanks
>  -- Daniel
>  From - Mon

-- 
Wilhelm