[1814] in bugtraq
Re: impossible vs. impractical
daemon@ATHENA.MIT.EDU (Tom Ptacek)
Sun May 14 18:01:01 1995
From: Tom Ptacek <lblack@onshore.com>
To: jon@netsys.com (jon)
Date: Sun, 14 May 1995 15:47:17 -0500 (CDT)
Cc: bugtraq@fc.net
In-Reply-To: <199505141935.MAA22658@netsys.com> from "jon" at May 14, 95 12:35:17 pm
> I have failed to do it with loose routing, however it's quite possible
> that one of intermidiate routers blocked it.
>
> However it worked with strict routing.
<shrug>
Did your loose route follow the same route as the strict one? Could it be
that you routed around whatever router was blocking you? That's weird,
but I've never played with strict routing before.
> You repeated my words here.
Sorry.
> RFC will not give you all information. All I meant was:
> if more filtering rules on the router are used AND ip source routing is NOT
> blocked you may find no use out of the filehandle you obtained from
> your source-routed mount request.
<ahhh> -click-
Ok, what you're saying is that getting a file handle from the mount
daemon doesn't do you a whole lot of good if you're blocked from the nfs
daemon? That I understand...
What I don't follow is the whole thing about "sometimes a file handle
will give you read access, sometimes none at all"... if a directory is
exported read only, yeah... but otherwise? Do you know of a way to
restrict write access on a read/write exported filesystem? Permissions, I
suppose... if you can't mask the 0 UID and everything's root owned, but
in that situation you might as well export read only anyways.
> You may apply filtering mechanisms that would reject packets that pretend tobe
> coming from your internal network through the network interface that handles all
> "external" traffic.
Yep. Works, too.
> Wrong approach
Care to be more specific?
--------------------------------------------------------------------
asriel@wookie.net
