Re: access control problem

Bryan,

A reverse lookup on the connecting IP shows the FQDN as host.mydomain.com.

Here's the debug output (grep'd for AccType)...

[Mon Nov  3 17:09:04 2003] conserver (15751): DEBUG: [access.c:147] AccType(): ip=172.16.72.207
[Mon Nov  3 17:09:04 2003] conserver (15751): DEBUG: [access.c:152] AccType(): who=127.0.0.1, tr
ust=a
[Mon Nov  3 17:09:04 2003] conserver (15751): DEBUG: [access.c:152] AccType(): who=mydomain.com,
 trust=a
[Mon Nov  3 17:09:05 2003] conserver (15751): ERROR: AccType(): gethostbyname(mydomain.com): hos
t lookup error
[Mon Nov  3 17:09:05 2003] conserver (15751): DEBUG: [access.c:152] AccType(): who=newdomain.com
, trust=a
[Mon Nov  3 17:09:06 2003] conserver (15751): ERROR: AccType(): gethostbyname(newdomain.com): ho
st lookup error

For grins, here's the access entry...

access * {
        allowed 127.0.0.1 ;
        allowed mydomain.com ;
        allowed newdomain.com ;
}

Using shortname, fqdn, ipaddress/mask, and exact ip all work. I've also
tried the entries all behind one 'allowed'.

-dolan


On Sat, 1 Nov 2003, Bryan Stansell wrote:

> Date: Sat, 1 Nov 2003 05:38:17 -0800
> From: Bryan Stansell <bryan@conserver.com>
> To: users@conserver.com
> Subject: access control problem (was Re: conserver-8.0.5 is available)
> 
> On Fri, Oct 31, 2003 at 06:14:01PM -0500, Michael Dolan wrote:
> > Recently upgraded to 8.0.4 (and now 8.0.5) from 7.2.7 and cannot get
> > acls for host access control to work properly. Configured with
> > --with-trustrevdns and specifying the domain names in conserver.cf,
> > but only get error (and refused connections). FQDN and IPaddrs work
> > fine. The conserver host can reverse lookup the FQDN properly.
> 
> well, sounds like you're doing the right thing.  --with-trustrevdns
> is necessary for it to work at all.  if you run in debug mode and grep
> out all the messages with AccType, we'd be able to see what it's doing
> and why it isn't allowing the connection (a bit better).
> 
> i do realize there's a problem with the logic used, and maybe that's the
> issue.  if you have a 'rejected' acl, that happen to match, after the
> domain acl, the reject acl will be processed before the domain acl and
> you'd get rejected.  things need to be adjusted so that all acls are
> processed in order - i goofed and didn't realize the impact when
> removing the reverse dns trust bits and then adding them back.
> 
> but, the debug info would tell us what's going on.
> 
> but
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
>