-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
George,
On 3/27/18 8:33 PM, George S. wrote:
> One thing that has bitten me is that the entire stack/call chain
> is examined, not just permissions on a specific piece of code as
> you would expect. This comes into play when you're trying to make
> calls into trusted code from a JSP.
JSP isn't an issue for me.
> My experience has been that JSPs are not trusted. So, even if you
> grant some code permissions to a specific codebase, the JSP making
> the call is untrusted and things fail. I ran into this recently
> using the Apache LDAP library with a JSP. A bunch of reads would
> fail.
>
> I see the tomcat security manager howto makes a reference to
> "pre-compiled jsp" but it's pretty vague (to my simple mind
> anyhow). I think the intention was to have pre-compiled JSPs live
> in a trusted codebase path.
Yes, that can be done e.g. by placing them into a JAR and trusting the
JAR.
> There's probably a way that you can mark all JSPs as trusted (I'm
> thinking a grant to $CATALINA_BASE/work/Catalina), but that kind of
> defeats the point. If you mark standard JSPs as trusted, then
> anyone that can get a file in the context path can bypass your
> security model.
>
> What I ended up doing on the last project was putting all of the
> code that made the calls into the Apache LDAP directory into a
> specific jar, and signing that jar with a certificate. Then I have
> a grant that trusts anything signed with that certificate.
I'd prefer to avoid signing if possible... we perform on-server builds
for everything, so that would mean distributing the signing-keys or
having a really awful process for building on-server and signing
off-server.
> The security manager can be maddening to work with. Just as a tip
> for my specific usage, I have a skeleton policy file and the tomcat
> startup script merges my policy file into Tomcat's policy file. I
> just found there's another way of doing that, but it doesn't look
> any better since it requires modifying a file in $JDK/JRE_HOME.
My plan was simply to append my own "additional" grants on to the end
of the Tomcat policy.
So far, I haven't had any luck using "grant" with ANY codebase at this
point.
Thanks,
- -chris
> On 3/22/2018 3:39 PM, Christopher Schultz wrote: All,
>
> I'm working on getting my application working under a
> SecurityManager. It's actually been a little less painful than I
> thought it would be.
>
> I'm using Solr for some index searching. I'm using SolrJ for the
> library to communicate via HTTP to a localhost Solr server. When
> using this grant:
>
> grant { permission "java.util.PropertyPermission"
> "solr.httpclient.builder.factory", "read"; permission
> "java.net.SocketPermission", "localhost:8983", "resolve,connect";
> }
>
> My application can can contact Solr without any errors.
>
> If I change the "grant" to include a codeBase to restrict those
> connections to the Solr library, I get a AccessControlException:
> access denied to the system property. Here is the modified grant:
>
>
> grant codeBase
> "file:${catalina.base}${file.separator}webapps${file.separator}myapp${
fi
>
>
le.separator}WEB-INF${file.separator}lib${file.separator}solr-solrj-7.2.
> 1.jar" { permission "java.util.PropertyPermission"
> "solr.httpclient.builder.factory", "read"; permission
> "java.net.SocketPermission" "localhost:8983", "resolve,connect";
> };
>
> I have verified that the file exists under the path specified
> above. I tried both ${file.separator} and '/' as the file
> separator. I also tried "jar:/path/to/jar!/-" as the codeBase. No
> luck.
>
> These grants are added to the end of the stock catalina.policy
> file that ships with Tomcat.
>
> What am I missing, here?
>
> -chris
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq76TkACgkQHPApP6U8
pFgA4xAApmyDP+TW+Ek4Q5iOH42CbH20eFD6pG1D1eMBTclZqygHCVTa6ZtWKqcK
UL1l+1ADVf2CVm3fnFj5mPcV/vv7N8i96ztotHFr2mX8Vbe9aNRjoSyvmTIi44UI
dUXOkWpD2/OoXsyvONql+dBKuvLWZWlf7bc+PDQEUuLWF2tVW7tPRJoeVqPfUftj
7dCl/E7uWwzfeW9oDw1pKdxmb2g5XzI9x5BGcoUYCaUGfhRnVP4/FXCG0pp/Jyhv
U6yp3xcmbGEsuYgyCOkLeWY4OcSHitco10oc+MbqNPZ7Jb5MpsQ0Rm3S3SKRXaYW
5fpx1LvDZn5yzk5SDnZbeawmL/WZntQEKOF9L3vDKiuLMwpiaLTOlM0mHTGVfVro
lesYmS58SdnEHPjS2ikfx1vsg7k+n43mSwuwz8zLmOBH479iGezVKbck+T9sVZqd
J7rc3XxX9hQHTPJSy6ToFZTRbjvlbHJu6vg9h6u0EO2aAuc/HIeRIJ/d1bHccrSJ
QudB6mnZqyrwdbaXT0fRb1B5Chy4r4IHdt5u/6pBS6ebEdNGOudCwRjMSP7Gmvj9
T7mWw3knx9WP4xpD7MUQx9iUoF4TNInmc68y3EZRRUS9ubwDxQ7njcK4rycKFVA1
1trARd6/4ofNG+Y2Hn998/3eSeN+xpbVNCN5SIAVpJBrJtIc+3U=
=8ijC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
