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] > >
