linux-kernel - Re: [PATCH 0/5] RFC: connector: Add network namespace awareness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 5 Jul 2020 22:32:06 +0000
From:   Matt Bennett <Matt.Bennett@...iedtelesis.co.nz>
To:     "christian.brauner@...ntu.com" <christian.brauner@...ntu.com>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "containers@...ts.linux-foundation.org" 
        <containers@...ts.linux-foundation.org>,
        "zbr@...emap.net" <zbr@...emap.net>
Subject: Re: [PATCH 0/5] RFC: connector: Add network namespace awareness

On Thu, 2020-07-02 at 21:10 +0200, Christian Brauner wrote:
> On Thu, Jul 02, 2020 at 08:17:38AM -0500, Eric W. Biederman wrote:
> > Matt Bennett <matt.bennett@...iedtelesis.co.nz> writes:
> > 
> > > Previously the connector functionality could only be used by processes running in the
> > > default network namespace. This meant that any process that uses the connector functionality
> > > could not operate correctly when run inside a container. This is a draft patch series that
> > > attempts to now allow this functionality outside of the default network namespace.
> > > 
> > > I see this has been discussed previously [1], but am not sure how my changes relate to all
> > > of the topics discussed there and/or if there are any unintended side effects from my draft
> > > changes.
> > 
> > Is there a piece of software that uses connector that you want to get
> > working in containers?

We have an IPC system [1] where processes can register their socket details (unix, tcp, tipc, ...) to a 'monitor' process. Processes can then get
notified  when other processes they are interested in start/stop their servers and use the registered details to connect to them. Everything works
unless a process crashes, in which case the monitoring process never removes their details. Therefore the monitoring process uses the connector
functionality with PROC_EVENT_EXIT to detect when a process crashes and removes the details if it is a previously registered PID.

This was working for us until we tried to run our system in a container.

> > 
> > I am curious what the motivation is because up until now there has been
> > nothing very interesting using this functionality.  So it hasn't been
> > worth anyone's time to make the necessary changes to the code.
> 
> Imho, we should just state once and for all that the proc connector will
> not be namespaced. This is such a corner-case thing and has been
> non-namespaced for such a long time without consistent push for it to be
> namespaced combined with the fact that this needs quite some code to
> make it work correctly that I fear we end up buying more bugs than we're
> selling features. And realistically, you and I will end up maintaining
> this and I feel this is not worth the time(?). Maybe I'm being too
> pessimistic though.
> 

Fair enough. I can certainly look for another way to detect process crashes. Interestingly I found a patch set [2] on the mailing list that attempts
to solve the problem I wish to solve, but it doesn't look like the patches were ever developed further. From reading the discussion thread on that
patch set it appears that I should be doing some form of polling on the /proc files.

Best regards,
Matt

[1] https://github.com/alliedtelesis/cmsg/blob/master/cmsg/src/service_listener/netlink.c#L61
[2] https://lkml.org/lkml/2018/10/29/638