Subject: Re: Flag to exclude an interface from INADDR_ANY?
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Jim Wise <>
List: tech-net
Date: 01/02/2002 11:33:23
Hash: SHA1

On Wed, 2 Jan 2002, der Mouse wrote:

>> Many daemons, including named, sshd, and sendmail, can be explicitly
>> given a set of interfaces to listen on.  [...]
>> Other daemons, including those mentioned, can only listen on
>> INADDR_ANY.  At this point, there is _no_ way to prevent them from
>> listening on an outside interface.  This would be addressed by the
>> new flag.
>Surely the right place to address this is the offending daemons, not by
>having the OS trying to hide some interfaces from them!  (And worse,
>not just from them, but from everyone, and in a really peculiar sense.)

Which is the same as saying daemons should never use INADDR_ANY, no?

At any rate, it seems unlikely that every daemon in tree is going to
support this anytime soon, never mind every daemon in pkgsrc.  And
commercial apps (and locally built apps run by users) are out of range
of the project even so.

At any rate, even were this achieved, it would mean finding eighty
different ways to configure different local daemons to obey what is
actually a system-wide setting during system configuration.  Being a
system-level setting, I would much prefer to be able to set it at a
system level...

>It does occur to me that what you really want here is the ability to
>specify a subset (not necessarily a proper subset) of the machine's
>addresses that INADDR_ANY listens to, preferably per-process (maybe
>even per-socket, though there's no obvious way to name sockets outside
>the context of a specific process).  Marking interfaces is almost
>certainly not the right way to do with this; if nothing else, it does
>not permit any control over interfaces that may appear in the future.
>Perhaps more importantly, it is the Wrong Thing if an interface has
>both an address that should be listened on and an address that
>shouldn't; you really want it per-address, not per-interface.

This is a valid point.  It may indeed be better to make this per
ifalias, not just per interface.  I'm not clear if this would be easier
or harder.

>IOW, while it may be a good enough fix for your environment, and as
>such may be a right thing for you, I would argue it is not generally
>enough Right to go into the tree.

It's not clear to me that it's less Right than using ipf to block access
to things which should never have been listening in the first place,
which is the only solution thing currently in tree...

- -- 
				Jim Wise
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see