I also favor enforcement even on intercept plugins. ip_allow is a white-listing function that is often configured to implement a security policy.
If one wishes to bypass it, then we could make such a thing explicit via the plugin API. On the other hand it would be nice of there were big, red, ugly warnings around any plugin API that could cause it to unexpectedly fail open. On Thu, Dec 6, 2018 at 4:43 PM Alan Carroll <solidwallofc...@oath.com.invalid> wrote: > This came up on a production system this week, and although I understand > what was going on, it's not so clear to me if this is a bug or a feature. > > If you set up ip_allow.config to block some specific methods, this access > check is done at the end of remapping. However, if a plugin calls > TSSkipRemappingSet(txn, 1), then remap is skipped, which skips end of > remap, which skips the access check. This is commonly done with intercept > plugins. In that case if the method in question is CONNECT, it looks like > the CONNECT went through, bypassing ip_allow, but it has actually been > intercepted and the CONNECT has connected to the intercept plugin, not the > destination in the CONNECT request. That can be nice - if I'm intercepting > transactions, I want to handle that kind of thing. It also seems reasonable > to take the view point that if ip_allow doesn't permit the request, it > shouldn't be permitted even for internal transactions. > > Overall, I think I favor enforcing ip_allow even on intercept plugins. Any > other thoughts? > > -- > *Beware the fisherman who's casting out his line in to a dried up > riverbed.* > *Oh don't try to tell him 'cause he won't believe. Throw some bread to the > ducks instead.* > *It's easier that way. *- Genesis : Duke : VI 25-28 > -- Derek
