netdev - Re: /proc/sys/net/ipv[46]/conf/ issue unsolved

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]

Message-ID: <9c46321e0702131007g5eaa291cpa8459715260b34c1@mail.gmail.com>
Date:	Tue, 13 Feb 2007 18:07:55 +0000
From:	"Hugo Santos" <hugosantos@...il.com>
To:	"Stephen Hemminger" <shemminger@...ux-foundation.org>
Cc:	"Hasso Tepper" <hasso@...pak.ee>, netdev@...r.kernel.org
Subject: Re: /proc/sys/net/ipv[46]/conf/ issue unsolved

Hi,

On 2/13/07, Stephen Hemminger <shemminger@...ux-foundation.org> wrote:
> > You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> > reenable it on the interfaces that you actually want.

  Is there any technical reason to not have the sysconf entries
available at interface creation? It seems to me that this solution is
very intrusive. Imagine for instance i'm developing some custom
application that uses a TAP interface and i don't want any
autoconfiguration over this interface. For instance a multi-homed host
creating a custom tunnel. Within the current rules i would have to
disable autoconfiguration system-wide to influence the expected
behaviour. Also, this is not reliable as a different application (or a
negligent user) may change back the sysconf values before i set the
TAP interface up.

  Unless there are strong technical reasons against it, it would seem
to me that having conf/tapX/{autoconf, accept_ra} (as an example)
available after the interface is created would provide the cleaner and
most reliable interface.

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