[TS-1983] ACL rules in remap.config does not take precedence over rules in ip_allow.config

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Fix Version/s: 8.0.0
• Component/s: Configuration
• Labels: incompatible
• Assignee: Alan M. Carroll
• Reporter: Leif Hedstrom
• Created: 28/Jun/13 16:00
• Updated: 07/Sep/16 00:40

Description

Lets say you want to allow DELETE for a small sub-set of requests, based on remap.config rules. The reasonable configuration is to do e.g.

map http://dav.example.com http://127.0.0.1 @method=DELETE @action=allow

However, this does not work, since the global "DENY" in ip_allow.config takes precedence (it denies all DELETE's). This is actually sort of a regression I think, it did not use to behave like this I'm fairly certain.

The workaround (which is incredibly cumbersom if you have even a moderately large remap.config, is to inverse the rules. E.g.

src_ip=0.0.0.0-255.255.255.255                    action=ip_deny  method=PUSH|PURGE

and

map http://other.example.com http://123 @method=DELETE @action=deny
map http://another.example.com http://123 @method=DELETE @action=deny
map http://more.example.com http://123 @method=DELETE @action=deny
.
.
.

This kinda sucks to maintain, and also opens up a PEBKAC security problem, when someone adds a new remap.config rule and forgets to deny the DELETEs.

I really feel that the ACLs from remap.config (if they match, you can specify IP ranges etc. as well), should take precedence over ip_allow.config.

Issue Links

• relates to: TS-4098 Remap filtering isn't working to only allow certain methods
• relates to: TS-4593 Extend ip_allow.config to filter destination IPs