That is caused by not wrapping the calls in PrivilegedActions in all the correct places and is a bug.
Tristan On 19/04/2017 11:34, Sebastian Laskawiec wrote: > The proposal look ok to me. > > But I would also like to highlight one thing - it seems you can't access > secured cache properties using CLI. This seems wrong to me (if you can > invoke the cli, in 99,99% of the cases you have access to the machine, > so you can do whatever you want). It also breaks healthchecks in Docker > image. > > I would like to make sure we will address those concerns. > > On Wed, Apr 19, 2017 at 10:59 AM Tristan Tarrant <ttarr...@redhat.com > <mailto:ttarr...@redhat.com>> wrote: > > Currently the "protected cache access" security is implemented as > follows: > > - if authorization is enabled || client is on loopback > allow > > The first check also implies that authentication needs to be in place, > as the authorization checks need a valid Subject. > > Unfortunately authorization is very heavy-weight and actually overkill > even for "normal" secure usage. > > My proposal is as follows: > - the "default" configuration files are "secure" by default > - provide clearly marked "unsecured" configuration files, which the user > can use > - drop the "protected cache" check completely > > And definitely NO to a dev switch. > > Tristan > > On 19/04/2017 10:05, Galder Zamarreño wrote: > > Agree with Wolf. Let's keep it simple by just providing extra > configuration files for dev/unsecure envs. > > > > Cheers, > > -- > > Galder Zamarreño > > Infinispan, Red Hat > > > >> On 15 Apr 2017, at 12:57, Wolf Fink <wf...@redhat.com > <mailto:wf...@redhat.com>> wrote: > >> > >> I would think a "switch" can have other impacts as you need to > check it in the code - and might have security leaks here > >> > >> So what is wrong with some configurations which are the default > and secured. > >> and a "*-dev or *-unsecure" configuration to start easy. > >> Also this can be used in production if there is no need for security > >> > >> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec > <slask...@redhat.com <mailto:slask...@redhat.com>> wrote: > >> I still think it would be better to create an extra switch to > run infinispan in "development mode". This means no authentication, > no encryption, possibly with JGroups stack tuned for fast discovery > (especially in Kubernetes) and a big warning saying "You are in > development mode, do not use this in production". > >> > >> Just something very easy to get you going. > >> > >> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño > <gal...@redhat.com <mailto:gal...@redhat.com>> wrote: > >> > >> -- > >> Galder Zamarreño > >> Infinispan, Red Hat > >> > >>> On 13 Apr 2017, at 09:50, Gustavo Fernandes > <gust...@infinispan.org <mailto:gust...@infinispan.org>> wrote: > >>> > >>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño > <gal...@redhat.com <mailto:gal...@redhat.com>> wrote: > >>> Hi all, > >>> > >>> As per some discussions we had yesterday on IRC w/ Tristan, > Gustavo and Sebastian, I've created a docker image snapshot that > reverts the change stop protected caches from requiring security > enabled [1]. > >>> > >>> In other words, I've removed [2]. The reason for temporarily > doing that is because with the change as is, the changes required > for a default server distro require that the entire cache manager's > security is enabled. This is in turn creates a lot of problems with > health and running checks used by Kubernetes/OpenShift amongst other > things. > >>> > >>> Judging from our discussions on IRC, the idea is for such > change to be present in 9.0.1, but I'd like to get final > confirmation from Tristan et al. > >>> > >>> > >>> +1 > >>> > >>> Regarding the "security by default" discussion, I think we > should ship configurations cloud.xml, clustered.xml and > standalone.xml with security enabled and disabled variants, and let > users > >>> decide which one to pick based on the use case. > >> > >> I think that's a better idea. > >> > >> We could by default have a secured one, but switching to an > insecure configuration should be doable with minimal effort, e.g. > just switching config file. > >> > >> As highlighted above, any secured configuration should work > out-of-the-box with our docker images, e.g. WRT healthy/running checks. > >> > >> Cheers, > >> > >>> > >>> Gustavo. > >>> > >>> > >>> Cheers, > >>> > >>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/ > (9.0.1-SNAPSHOT tag for anyone interested) > >>> [2] > > https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118 > >>> -- > >>> Galder Zamarreño > >>> Infinispan, Red Hat > >>> > >>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <ttarr...@redhat.com > <mailto:ttarr...@redhat.com>> wrote: > >>>> > >>>> Dear all, > >>>> > >>>> after a mini chat on IRC, I wanted to bring this to > everybody's attention. > >>>> > >>>> We should make the Hot Rod endpoint require authentication in the > >>>> out-of-the-box configuration. > >>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL > >>>> mechanism against the ApplicationRealm and require users to > run the > >>>> add-user script. > >>>> This would achieve two goals: > >>>> - secure out-of-the-box configuration, which is always a good idea > >>>> - access to the "protected" schema and script caches which is > prevented > >>>> when not on loopback on non-authenticated endpoints. > >>>> > >>>> Tristan > >>>> -- > >>>> Tristan Tarrant > >>>> Infinispan Lead > >>>> JBoss, a division of Red Hat > >>>> _______________________________________________ > >>>> infinispan-dev mailing list > >>>> infinispan-dev@lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >>> > >>> > >>> _______________________________________________ > >>> infinispan-dev mailing list > >>> infinispan-dev@lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >>> > >>> _______________________________________________ > >>> infinispan-dev mailing list > >>> infinispan-dev@lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev@lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> -- > >> SEBASTIAN ŁASKAWIEC > >> INFINISPAN DEVELOPER > >> Red Hat EMEA > >> > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev@lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev@lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > > SEBASTIANŁASKAWIEC > > INFINISPAN DEVELOPER > > Red HatEMEA <https://www.redhat.com/> > > <https://red.ht/sig> > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev