On 09/23/2009 05:37 PM, Andrew Dunstan wrote:
> Tom Lane wrote:
>> In this case what particularly scares me is the idea that 'samenet'
>> might be interpreted to let in a larger subnet than the user expected,
>> eg 10/8 instead of 10.0.0/24. You'd likely not notice the problem until
>> after you'd been broken into ...
>>
>
> I haven't looked at this "feature" at all, but I'd be inclined, on the
> grounds you quite reasonably cite, to require a netmask with
> "samenet", rather than just ask the interface for its netmask.
I think requiring a netmask defeats some of the value of samenet. When
being assigned a new address can change subnet as well. For example,
when we moved one of our machines from one room to another it went from
/24 to /26.
I think it should be understood that the network will not work properly
if the user has the wrong network configuration. If they accidentally
use /8 instead of /24 on their interface - it's more likely that some or
all of their network will become inaccessible, than somebody breaking
into their machine. And, anything is better than 0.0.0.0.
There are two questions here I think - one is whether or not samenet is
valid and would provide value, which I think it is and it does. A second
question is whether it should be enabled in the default pg_hba.conf - I
think not.
Postfix has this capability and it works fine. I use it to allow relay
email from machines I "trust", because they are on my network. I think
many people would use it, and it would be the right solution for many
problems. Worrying about how some person somewhere might screw up, when
they have the same opportunity to screw up if things are left unchanged
(0.0.0.0) is not a practical way of looking at things.
How many Postfix servers have you heard of being open relays as a result
of "samenet"? I haven't heard of it ever happening. I suppose it doesn't
mean it hasn't happened - but I think getting the network interface
configured properly being a necessity for the machine working properly
is a very good encouragement for it to work.
Cheers,
mark
--
Mark Mielke<mark@mielke.cc>
