netdev - RFC: pid "ownership" of ip config information

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-next>] [day] [month] [year] [list]

Message-ID: <1295602091.3582.1.camel@lat1>
Date:	Fri, 21 Jan 2011 10:28:11 +0100
From:	Patrick Schaaf <netdev@....de>
To:	netdev@...r.kernel.org
Subject: RFC: pid "ownership" of ip config information

Dear netdev,

I want to solicit comments on a feature enhancement that occured
to me recently.

Feature:

- For "ip addr add", "ip route add", "ip rule add", and maybe "ip link
add",
  implement an option 'pid XXXXX' to specify a PID
- if that PID is not currently existing, fail the operation
- if, at a later time, that PID dies, automatically remove the
configuration,
  as if a corresponding "ip ... del" would have been given

The feature would be useful in any kind of "IP takeover" scenario.

I'm concretely working on deployment of keepalived (VRRP address
takeover) and memcachedb (address takeover after berkeley DB master
selection).

It would also apply to all kinds of routing daemons (zebra, quagga...).

In all these cases, for as long as the process is working normally,
it can trigger the relevant address withdrawal, but when the process
dies unexpectedly (oom killer or whatever), addresses are left
configured,
while a partner on another host might take them over, resulting in
actively duplicate IPs and the application breaking.

The alternative to such a feature, would be to have an additional
monitoring process, which would watch the PID somehow, and need to
be configured to know what to withdraw when it dies.

Before I go ahead and try to implement that, I would like to have
some feedback regarding the idea 

- has it been discussed before?
- would it be accepted by the relevant maintainers? 
- did I overlook alternative solutions to the problem?

best regards
  Patrick

--
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