Re: Redundant and pointless use of ACL peername (ITS#1515)

[mark.blackman@netscalibur.co.uk]

Whoops. Sorry about that. Mucho apologies. I should have
looked harder at the code before jumping to conclusions.

I had a feeling I was wrong about the sockname business
but was in a bit of a rush. Anyway, consider me very chastised
in that respect. That's embarassing.

In any case, I came to the same conclusion about peername
restrictions (in the case of exact matches) being handled better by 
something like tcp wrappers, but I have a requirement to differentiate
between different levels of access for a set of IP addresses.
Some need to read and some need to auth only for a given RDN.

Unless I'm mistaken yet again, TCP wrappers and the ilk tend
to provide binary access only.

In the end, I'd concur that a new kind of basic style 
along the lines indicated is required to meet my requirements. I presume 
you'd rather see patches than mere suggestions.

Apologies for my hasty reading.

Cheers,
Mark


On Tue, Jan 08, 2002 at 09:49:35AM -0800, Kurt D. Zeilenga wrote:
> At 08:08 AM 2002-01-08, you wrote:
> >Full_Name: Mark Blackman
> >Version: 2.0.19
> >OS: FreeBSD 4.4
> >URL: http://www.users.dircon.co.uk/~canyon/patches/peername.patch-2.0.19
> >Submission from: (NULL) (195.157.3.43)
> >
> >
> >Both the peername and sockname <who> clauses use exactly the same format and
> >thus one is redundant.
> 
> peername and sockname are not redundant.  Together they describe
> both endpoints of a stream.  sockname describes the server end
> point and the peername describes client end point.  They share
> the same format, but provide different information.
> 
> >(see servers/slapd/slap.h and servers/slapd/daemon.c
> >for construction of peername and sl_name )
> >
> >Additionally as both peername and sockname include the port number of 
> >the client socket,
> 
> Peername includes the port number of the client endpoint of the stream.
> Sockname includes the port number of the server endpoint of the stream.
> 
> >its (nearly) impossible to actually predict what it
> 
> (it here refers to the client endpoint port number)
> 
> Depends on the environment.  One could have clients that bind to
> a particular port known by the server.  But, yes, most clients
> don't do that and hence the port number is generally not predictable.
> Which means that exact matching the peername makes little sense.
> 
> But for sockname, the port is quite predicable as the server
> always binds to a particular ports.
> 
> >will look like and thus exact matching (as opposed to regex matching)
> >in ACLs is (nearly) impossible.
> 
> It's possible, it just doesn't make sense in many cases.
> 
> >I propose that sockname retain this current behaviour but that peername
> >actually be a simple ASCII form of the IP address (IP4 or IP6) and
> >continue the current behaviour for the case of UNIX domain sockets
> >(i.e. peername = "PATH=/tmp/.unixdomainsocket). Thus peername will
> >look like one of 
> 
> Changing the format or information in peername would break things.
> 
> A better approach would be introduce some other form of matching,
> such as mask width w/ optional port.
>         by peername.mask="IP=10.0.0.0/16" read
>         by peername.mask="IP=192.168.128.0:255.255.240.0" read
>         by peername.maks="IP=172.16.0.1-172.16.0.15:389" read
> 
> would grant read to following range of peer IP addresses,
> regardless of port:
>         10.0.0.0 - 10.0.255.255
>         192.168.128.0 - 192.168.143.255
> 
> and:
>         172.16.0.1 - 172.16.0.15
> iif the peer port was 389.
> 
> I note that I generally suggest that IP/TCP filtering mechanisms
> (tcp wrappers, firewall, etc.) be used instead of the peername
> mechanism.
> 
>