A couple of other things to keep in mind to make sure you aren't introducing security holes
1) Queries can be executed by users with read privileges. So if it needs to be really clear to the operator whether the MethodInvocationAuthorizer they are configuring is going to let users call methods that modify the data or not. 2) OQL lets you invoke methods on objects that are passed as parameters to the query. So that means that any class that exists on the server and is serializable could potentially have methods invoked in it through a query when someone opens up access with one of these MethodInvocationAuthorizers. So the RegexBasedMethodAuthorizer needs to be used with care. -Dan On Tue, Jun 25, 2019 at 11:53 AM Anthony Baker <aba...@pivotal.io> wrote: > Here are the things I think are important: > > 1) I shouldn’t have to change my domain classes in order to run a query. > 2) I shouldn’t have to configure anything to run a “normal” query that > uses classes deployed into the cluster and stored in the region. > 3) By default the cluster is secure from malicious users trying to execute > untrusted code*. > > > Anthony > > * if a user chooses to deploy code into the cluster that does bad things > that’s on them > > > > On Jun 25, 2019, at 11:07 AM, Aaron Lindsey <alind...@pivotal.io> wrote: > > > > +1 to the proposal > > > > Some comments: > > > > - There is almost always trade-off between security and ease-of-use. > The > > proposed implementation of JavaBeanAccessorBasedMethodAuthorizer makes > me > > feel uneasy because it would be super easy to create a method that > begins > > with "get" or "is" but is not actually a JavaBean accessor method. > However, > > I can also see how nice this would be in terms of ease-of-use. > > - From a security standpoint I prefer AnnotationBasedMethodAuthorizer > > because it's very explicit on which methods may be executed. To remove > the > > coupling between the configuration and domain classes, you could > separate > > out the mapping of which methods are allowed into a different class > and not > > use annotations. > > - How have other projects solved this problem? Can we add a "related > > work" section to the proposal? If you've already looked and didn't > really > > find anything relevant you could also mention that in the proposal. > > > > - Aaron > > > > > > On Mon, Jun 24, 2019 at 4:31 PM Jason Huynh <jhu...@pivotal.io> wrote: > > > >> +1 > >> > >> I have some concerns about all of the different ways we configure geode > to > >> be secure, but that's a different issue ;-) > >> Overall, very thorough proposal Juan! > >> > >> > >> > >> On Mon, Jun 24, 2019 at 4:22 PM Dan Smith <dsm...@pivotal.io> wrote: > >> > >>> +1 > >>> > >>> This proposal looks good to me! > >>> > >>> On Mon, Jun 24, 2019 at 4:15 PM Udo Kohlmeyer <u...@apache.org> wrote: > >>> > >>>> +1, Count me in > >>>> > >>>> On 6/24/19 13:06, Juan José Ramos wrote: > >>>>> Hey Jake, > >>>>> > >>>>> Sure, I guess we could do a live session if there's enough interest > >>> after > >>>>> people have reviewed the proposal. > >>>>> Best regards. > >>>>> > >>>>> On Mon, Jun 24, 2019 at 4:17 PM Jacob Barrett <jbarr...@pivotal.io> > >>>> wrote: > >>>>> > >>>>>> > >>>>>>> On Jun 24, 2019, at 11:49 AM, Juan José Ramos <jra...@pivotal.io> > >>>> wrote: > >>>>>>> > >>>>>>> I’d rather get feedback in any way and aggregate everything on my > >>> own > >>>>>> than > >>>>>>> maybe not getting anything because I'm explicitly limiting the > >>> options > >>>> to > >>>>>>> provide it. > >>>>>> Dealers choice so both it is! > >>>>>> > >>>>>> Could you also consider public live session on some medium, like > >> Zoom, > >>>>>> where you can walk through the proposal and take like feedback and > >>>>>> questions? > >>>>>> > >>>>>> Thanks, > >>>>>> Jake > >>>>>> > >>>>>> > >>>>>> > >>>> > >>> > >> > >
