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

[Kurt@OpenLDAP.org]

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.