[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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.


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) (
> >
> >
> >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=" read
>         by peername.mask="IP=" read
>         by peername.maks="IP=" read
> would grant read to following range of peer IP addresses,
> regardless of port:
> -
> -
> and:
> -
> 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.