Hi Alex, Will it be possible to specify host name in the rule and restrict the > access to the specified virtual host? > > As you pointed out, this is not possible from the Firewall plugin. I am trying to limit the scope of this work to be a "functionally neutral" change, so I would prefer to not make this enhancement for now.
It is of course possible to specify an ACL file for each virtualhost if the user requires fine-grained control. > Another question I have about adding predicates "from-network" and > "from-hostname". > Why we cannot provide the network or host name pattern as part of > user/group name? > For example, using the following constructions > > ACL ALLOW all/123.456.789/24 ACCESS VIRTUALHOST > ACL DENY-LOG my-user-group/.*\.uat.mycompany\.com ACCESS VIRTUALHOST > > That's an interesting idea. My personal preference is to keep the user/group field separate from the from-network/from-hostnames fields. I think the advantage of your proposal -- namely succinctness -- is outweighed by the pitfalls (both from a developer and a user point of view) of escaping the slash or @ characters that might occur in the user or group name. Phil On 25 September 2012 14:19, Oleksandr Rudyy <[email protected]> wrote: > Hi Phil, > > Existing firewall plugin denies/allows access to broker from > network/host regardless virtual host. > The suggested syntax implies that you can denies/allows access to the > broker virtual hosts instead. > Will it be possible to specify host name in the rule and restrict the > access to the specified virtual host? > > Another question I have about adding predicates "from-network" and > "from-hostname". > Why we cannot provide the network or host name pattern as part of > user/group name? > For example, using the following constructions > > ACL ALLOW all/123.456.789/24 ACCESS VIRTUALHOST > ACL DENY-LOG my-user-group/.*\.uat.mycompany\.com ACCESS VIRTUALHOST > > It looks like that existing ACL syntax allows to specify the user > domain after character '/'. I would prefer to use '@' for this but it > seems this character is reserved to specify the user realm. > > Alex > > On 25 September 2012 10:07, Phil Harvey <[email protected]> wrote: > > Thanks for the feedback guys. > > > > Responding to Chuck's questions: > > > >> Your proposed syntax is basically OK. The C++ broker supports IPv4, > >> IPv6, and RDMA. Could you specify the "--from-network xxxx" property > >> more fully? > > > > As suggested by Robbie, the from-network and from-hostname properties > will > > retain the semantics of the similarly-named properties in the existing > > firewall plugin ( > https://cwiki.apache.org/qpid/firewall-configuration.html), > > such that this task is a "functionally neutral" refactoring. I think any > > functional enhancements that arise (eg to match the C++ broker's firewall > > support) should be done under a separate JIRA. > > > > > >> Do you think this can make it in the next release? > > > > Yes, I expect to submit a patch in the next few days. > > > > > > Unless there are any further objections I'm going to proceed with this > > JIRA. > > > > Phil > > > > > > On 25 September 2012 01:52, Robbie Gemmell <[email protected]> > wrote: > > > >> Where the Java broker is concerned it wasnt moved in the timeframe of > that > >> mail thread simply because the ACL system in use at the time was limited > >> and in need of removal more than anything else (which happened some time > >> ago), so it didnt make sense to combine them at the time and it just > hasn't > >> happened since it did become worthwhile. Now there are new reasons it > would > >> be useful to combine them, to the extent it makes enough sense for us to > >> combine the functionality now rather than later. > >> > >> I cant really say I recall any other discussions on this subject except > the > >> other postings on JIRA and/or the user list requesting the > functionality it > >> would offer. > >> > >> Robbie > >> > >> On 25 September 2012 01:19, Rajith Attapattu <[email protected]> > wrote: > >> > >> > I'm not really against the change proposed by Philip. > >> > But wanted to highlight the history around this area, in case anybody > >> > remembers the reasons behind abandoning the previous effort. > >> > It's always best to make a decision after considering all aspects. > >> > I hope somebody still remembers why this didn't take place. > >> > > >> > Rajith > >> > > >> > On Mon, Sep 24, 2012 at 8:05 PM, Robbie Gemmell > >> > <[email protected]> wrote: > >> > > The previous thread in [1] is of little relevance now as none of the > >> ACL > >> > > code under discussion there exists anymore. It is easy enough to > argue > >> > that > >> > > such restrictions would are best served by a real firewall, but > there > >> are > >> > > reasons it still proves useful functionality for the broker to have > and > >> > we > >> > > have users we want to keep supporting the functionality for, even > if we > >> > are > >> > > changing the config (which doesnt particularly concern me, we are > >> slowly > >> > > moving towards an end state with config on the Java broker that will > >> > change > >> > > config for almost everything..making this change now will just > reduce > >> the > >> > > amount of future change slightly). Ultimately the functionality > already > >> > > exists, simplistically this is just going to be tweaking where the > >> > > implementation lives and its config, though in the end it may > actually > >> > add > >> > > functionality too as a side effect (e.g. user specific network > >> > restriction, > >> > > which I dont think is currently supported on the Java side). > >> > > > >> > > The docs for the existing xml config for the Java broker effort > lives > >> at > >> > > https://cwiki.apache.org/qpid/firewall-configuration.html and > details > >> > its > >> > > current hostname wildcarding and CIDR network matching. > >> > > > >> > > Robbie > >> > > > >> > > On 24 September 2012 21:23, Rajith Attapattu <[email protected]> > >> wrote: > >> > > > >> > >> The last time this came up for discussion there was some push back > on > >> > the > >> > >> list. > >> > >> This was proposed here [1] due to some requests from the users and > >> > >> there was even a patch for the c++ broker attached here [2] > >> > >> However this didn't go through due to some discussion that > happened on > >> > the > >> > >> list. > >> > >> Unfortunately I can't seem to find a reference to this on the > mailing > >> > >> list archives. > >> > >> > >> > >> Does anybody recall the reasons ? > >> > >> > >> > >> I vaguely remember that one of the reasons was that this could be > >> > >> handled more effectively with a firewall than ACL. > >> > >> > >> > >> [1] > >> > >> > >> > > >> > http://apache-qpid-developers.2158895.n2.nabble.com/IP-white-lists-for-brokers-td4127195.html > >> > >> [2] https://issues.apache.org/jira/browse/QPID-2305 > >> > >> > >> > >> On Mon, Sep 24, 2012 at 3:33 PM, Chuck Rolke <[email protected]> > >> wrote: > >> > >> > I think the proposal makes sense and I'd like to see it common to > >> all > >> > >> brokers. > >> > >> > > >> > >> > To date the C++ broker ACL code has used only literal text > strings > >> for > >> > >> host names as defined by the connection agent. Resolving network > names > >> > >> and/or subnets adds new code. > >> > >> > > >> > >> > Your proposed syntax is basically OK. The C++ broker supports > IPv4, > >> > >> IPv6, and RDMA. Could you specify the "--from-network xxxx" > property > >> > more > >> > >> fully? > >> > >> > > >> > >> > Do you think this can make it in the next release? > >> > >> > > >> > >> > -Chuck > >> > >> > > >> > >> > ----- Original Message ----- > >> > >> >> From: "Phil Harvey" <[email protected]> > >> > >> >> To: [email protected] > >> > >> >> Sent: Monday, September 24, 2012 11:14:48 AM > >> > >> >> Subject: Java broker proposal: move firewall rules into ACL file > >> > >> (QPID-4334) > >> > >> >> > >> > >> >> I'm working on https://issues.apache.org/jira/browse/QPID-4334 > >> > >> >> ("[Java > >> > >> >> broker] move the Firewall functionality into the ACL plugin") > and > >> > >> >> want to > >> > >> >> gather opinions on the desired behaviour. > >> > >> >> > >> > >> >> My main questions are: > >> > >> >> - Are we happy to make this change to the Java Broker? > >> > >> >> - If so, what is the nicest ACL syntax for firewall rules? > >> > >> >> > >> > >> >> The motivation for this work is to: > >> > >> >> > >> > >> >> (1) rationalise our set of plugins, thus making the > implementation > >> of > >> > >> >> QPID-4335 ("[java broker] replace current plugin system with a > >> > >> >> simplified > >> > >> >> system") easier; > >> > >> >> (2) make life simpler for our users. > >> > >> >> > >> > >> >> I expect the second point will be more contentious, hence this > >> email. > >> > >> >> > >> > >> >> Putting myself in the user's shoes, I believe it makes sense for > >> > >> >> access > >> > >> >> control and firewall configuration to be done in one place, > using > >> > >> >> rules > >> > >> >> such as: > >> > >> >> > >> > >> >> ACL ALLOW all ACCESS VIRTUALHOST FROM-NETWORK="123.456.789/24" > >> > >> >> ACL DENY-LOG all ACCESS VIRTUALHOST > >> > >> >> FROM-HOSTNAME=".*\.uat.mycompany\.com" > >> > >> >> > >> > >> >> I therefore propose to enhance the "ACCESS VIRTUALHOST" ACL > rule to > >> > >> >> support > >> > >> >> the same network and hostname predicates that are currently > >> supported > >> > >> >> by > >> > >> >> the firewall Java broker plugin. This will make the firewall > >> plugin > >> > >> >> redundant, so it will be deleted. > >> > >> >> > >> > >> >> The objections I'm anticipating are: > >> > >> >> > >> > >> >> - This will break require users to modify their config when they > >> > >> >> upgrade. > >> > >> >> I think this minor inconvenience is outweighed by the > motivations > >> > >> >> stated > >> > >> >> above. > >> > >> >> > >> > >> >> - This will cause the Java and C++ ACL syntax to diverge > further. > >> I > >> > >> >> don't > >> > >> >> know if this is a showstopper. I understand that this > enhancement > >> > >> >> was > >> > >> >> previously discussed for the C++ broker, and I'd be particularly > >> > >> >> interested > >> > >> >> to hear current views on this from the C++ folks. > >> > >> >> > >> > >> >> Let me know what you think. > >> > >> >> > >> > >> >> Thanks > >> > >> >> Phil > >> > >> >> > >> > >> > > >> > >> > > >> --------------------------------------------------------------------- > >> > >> > To unsubscribe, e-mail: [email protected] > >> > >> > For additional commands, e-mail: [email protected] > >> > >> > > >> > >> > >> > >> > --------------------------------------------------------------------- > >> > >> To unsubscribe, e-mail: [email protected] > >> > >> For additional commands, e-mail: [email protected] > >> > >> > >> > >> > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
