Re: blank html frames in Jenkins-built documentation
Thanks, Uwe and Chris. The change described on
https://issues.apache.org/jira/browse/INFRA-11746 seems to have fixed
the problem. I can now see Derby's Jenkins-generated, frames-based,
html-formatted alpha docs.
Thanks,
-Rick
On 4/25/16 4:19 PM, Uwe Schindler wrote:
I opened https://issues.apache.org/jira/browse/INFRA-11746
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Andrew Bayer [mailto:andrew.ba...@gmail.com]
Sent: Sunday, April 24, 2016 8:09 PM
To: bui...@apache.org
Cc: Rick Hillegas<rick.hille...@gmail.com>; derby-...@db.apache.org
Subject: Re: blank html frames in Jenkins-built documentation
Please open an INFRA JIRA.
On Sunday, April 24, 2016, Uwe Schindler<uschind...@apache.org> wrote:
Hi,
We have the same problem with our Lucene documentation. Some Lucene
classes refer to JDK documentation. The links just result in a white page
and the mentioned security warning in browser logs.
For other Jenkins servers outside ASF the setting to disable this checks
were added to prevent the javadocs problem.
Unless Java 9 with the new Javadocs style comes, it is impossible to
display Javadocs of previous versions with the frame security issues.
Please disable this as described in Jenkins Wiki. Our build servers are
under full control by infrastructure and comitters. Nobody from the outside
can inject custom pages loaded in frames.
Uwe
Am 24. April 2016 16:34:16 MESZ, schrieb Rick Hillegas<
rick.hille...@gmail.com<javascript:;>>:
Hi Infrastructure experts,
The Derby project uses Jenkins to build the latest version of our user
documentation. The resulting documents are linked from the Derby
website
here: http://db.apache.org/derby/manuals/index.html#latest. Some of
the
Jenkins-built documentation is in html format and it uses frames. The
Jenkins machines serve up those web pages as blank frames and my
Firefox
browser's error console reports the following:
Content Security Policy: Couldn't process unknown directive 'sandbox'
Content Security Policy: The page's settings blocked the loading of a
resource at
https://builds.apache.org/job/Derby-
docs/lastSuccessfulBuild/artifact/trunk/out/ref/toc.html
("default-src 'none'").
The frames seem to have been intercepted in order to frustrate a
possible Cross Frame Scripting attack, as described by the default
Jenkins Content Security Policy:
https://wiki.jenkins-
ci.org/display/JENKINS/Configuring+Content+Security+Policy#ConfiguringCo
ntentSecurityPolicy-Considerations
The default Jenkins Content Security Policy assumes that Apache
continuous-integration builds are exposed to the two risks listed here:
https://wiki.jenkins-
ci.org/display/JENKINS/Configuring+Content+Security+Policy#ConfiguringCo
ntentSecurityPolicy-Considerations
. I don't believe that Apache's Jenkins builds suffer from the first
risk ("Are less trusted users allowed to create or modify files in
Jenkins workspaces?"). That is because only trusted Apache committers
can trigger Jenkins builds. Do Apache continuous-integration builds
suffer from the second risk ("Are some slaves not fully trusted?").
The Derby developers have begun discussing this problem at
http://apache-database.10148.n7.nabble.com/alpha-docs-not-being-
generated-td145918.html
. I would appreciate your advice about how we can stop html frames from
being intercepted and blanked out when readers link to the
Jenkins-built
documentation.
Thanks,
-Rick
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5471) Classloader issues when running Lucene under a java SecurityManager
[
https://issues.apache.org/jira/browse/LUCENE-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13917204#comment-13917204
]
Rick Hillegas edited comment on LUCENE-5471 at 3/1/14 9:58 PM:
---
Attaching a third version of SecureLucene.java. I have wrapped a privilege
block around the application's Lucene calls and pruned some more permissions.
This significantly reduces the attack surface.
At this point, I do not need to grant Lucene any runtime or reflection
permissions and I do not need to grant Lucene read access to all of the files
in the file system. I do not need to grant the application read access to all
files in the file system, either. It turns out that Codec loading simply
depends on the ability to read the Lucene core jar file.
Here are the reduced permissions which I need to grant:
{noformat}
grant codeBase
file:/Users/rh161140/derby/derby-590/trunk/tools/java/lucene-core-4.5.0.jar
{
// permissions for file access, write access only to sandbox:
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest, read,write,delete;
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest/-, read,write,delete;
// Basic permissions needed for Lucene to work:
permission java.util.PropertyPermission user.dir, read;
permission java.util.PropertyPermission sun.arch.data.model, read;
};
grant codeBase file:/Users/rh161140/src/
{
// permissions for file access, write access only to sandbox:
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/trunk/tools/java/lucene-core-4.5.0.jar,
read;
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest, read,write;
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest/-, read,write,delete;
// Basic permissions needed for Lucene to work:
permission java.util.PropertyPermission user.dir, read;
permission java.util.PropertyPermission sun.arch.data.model, read;
};
{noformat}
was (Author: rhillegas):
Attaching a third version of SecureLucene.java. I have wrapped a privilege
block around the application's Lucene calls and pruned some more permissions.
This significantly reduces the attack surface.
At this point, I do not need to grant Lucene any runtime or reflection
permissions and I do not need to grant Lucene read access to all of the files
in the file system. I do not need to grant the application read access to all
files in the file system, either. It turns out that Codec loading simply
depends on the ability to read the Lucene core jar file.
Here are the reduced permissions which I need to grant:
grant codeBase
file:/Users/rh161140/derby/derby-590/trunk/tools/java/lucene-core-4.5.0.jar
{
// permissions for file access, write access only to sandbox:
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest, read,write,delete;
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest/-, read,write,delete;
// Basic permissions needed for Lucene to work:
permission java.util.PropertyPermission user.dir, read;
permission java.util.PropertyPermission sun.arch.data.model, read;
};
grant codeBase file:/Users/rh161140/src/
{
// permissions for file access, write access only to sandbox:
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/trunk/tools/java/lucene-core-4.5.0.jar,
read;
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest, read,write;
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest/-, read,write,delete;
// Basic permissions needed for Lucene to work:
permission java.util.PropertyPermission user.dir, read;
permission java.util.PropertyPermission sun.arch.data.model, read;
};
Classloader issues when running Lucene under a java SecurityManager
---
Key: LUCENE-5471
URL: https://issues.apache.org/jira/browse/LUCENE-5471
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.5
Reporter: Rick Hillegas
Attachments: SecureLucene.java, SecureLucene.java
I see the following error when I run Lucene 4.5.0 under a java
SecurityManager. I will attach a test program which shows this problem. The
program works fine when a SecurityManager is not installed. But the program
fails when I install a SecurityManager. Even more puzzling, the program works
if I first run it without a SecurityManager, then install a SecurityManager,
then re-run the program, all within the lifetime of a single JVM. I would
appreciate advice about how to work around this problem:
Exception in thread main java.lang.ExceptionInInitializerError
at
org.apache.lucene.index.LiveIndexWriterConfig.init(LiveIndexWriterConfig.java:122
[jira] [Commented] (LUCENE-5471) Classloader issues when running Lucene under a java SecurityManager
[
https://issues.apache.org/jira/browse/LUCENE-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914731#comment-13914731
]
Rick Hillegas commented on LUCENE-5471:
---
Thanks for the help and the discussion so far, Hoss and Uwe.
Attaching a second rev of the SecureLucene test program. This version pares
back the permissions in order to expose the minimal attack surface which I can
configure by myself. Here are the minimal permissions which the test program
grants in order to run successfully under a Java Security Manager:
{noformat}
// permissions granted to Lucene
grant codeBase
file:/Users/rh161140/derby/derby-590/trunk/tools/java/lucene-core-4.5.0.jar
{
// permissions for file access, write access only to sandbox:
permission java.io.FilePermission ALL FILES, read;
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest, read,write,delete;
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest/-, read,write,delete;
// Basic permissions needed for Lucene to work:
permission java.util.PropertyPermission user.dir, read;
permission java.util.PropertyPermission sun.arch.data.model, read;
permission java.lang.reflect.ReflectPermission *;
permission java.lang.RuntimePermission *;
};
// permissions granted to the application
grant codeBase file:/Users/rh161140/src/
{
// permissions for file access, write access only to sandbox:
permission java.io.FilePermission ALL FILES, read;
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest, read,write;
permission java.io.FilePermission
/Users/rh161140/derby/derby-590/luceneTest/-, read,write,delete;
// Basic permissions needed for Lucene to work:
permission java.util.PropertyPermission user.dir, read;
permission java.util.PropertyPermission sun.arch.data.model, read;
};
{noformat}
I have some follow on comments and questions:
1) Is it really necessary to grant Lucene every RuntimePermission and the
privilege to read every file in the file system? Maybe these grants can be
tightened.
2) I don't understand why the calling, application code needs to be granted any
permissions. Maybe some more privilege blocks could be added to the Lucene
code? In particular, it seems a shame that the application has to be granted
the privilege to read every file in the file system.
3) Most of the application permissions are self-revealing. That is, if I omit
one of them, then I get an exception telling me that the permission needs to be
granted. However, that is not the case for the first permission granted to the
application...
permission java.io.FilePermission ALL FILES, read;
...Without that permission, I get the original puzzling exception: Caused by:
java.lang.IllegalArgumentException: A SPI class of type
org.apache.lucene.codecs.Codec..., which doesn't really tell me what the
problem is. Maybe the wording of that exception could be improved so that the
user can be told that one of its root causes is a failure to grant the
application and Lucene read access to every file in the file system.
Thanks,
-Rick
Classloader issues when running Lucene under a java SecurityManager
---
Key: LUCENE-5471
URL: https://issues.apache.org/jira/browse/LUCENE-5471
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.5
Reporter: Rick Hillegas
Attachments: SecureLucene.java
I see the following error when I run Lucene 4.5.0 under a java
SecurityManager. I will attach a test program which shows this problem. The
program works fine when a SecurityManager is not installed. But the program
fails when I install a SecurityManager. Even more puzzling, the program works
if I first run it without a SecurityManager, then install a SecurityManager,
then re-run the program, all within the lifetime of a single JVM. I would
appreciate advice about how to work around this problem:
Exception in thread main java.lang.ExceptionInInitializerError
at
org.apache.lucene.index.LiveIndexWriterConfig.init(LiveIndexWriterConfig.java:122)
at
org.apache.lucene.index.IndexWriterConfig.init(IndexWriterConfig.java:165)
at SecureLucene$1.run(SecureLucene.java:129)
at SecureLucene$1.run(SecureLucene.java:122)
at java.security.AccessController.doPrivileged(Native Method)
at SecureLucene.getIndexWriter(SecureLucene.java:120)
at SecureLucene.runTest(SecureLucene.java:72)
at SecureLucene.main(SecureLucene.java:52)
Caused by: java.lang.IllegalArgumentException: A SPI class of type
org.apache.lucene.codecs.Codec with name 'Lucene45' does not exist. You need
to add the corresponding JAR file supporting this SPI to your classpath.The
current classpath supports the following names
[jira] [Updated] (LUCENE-5471) Classloader issues when running Lucene under a java SecurityManager
[ https://issues.apache.org/jira/browse/LUCENE-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated LUCENE-5471: -- Attachment: SecureLucene.java Attaching SecureLucene.java, a program which shows this problem. To run the program, I put the program and the following jar files on the classpath: lucene-analyzers-common-4.5.0.jar lucene-core-4.5.0.jar lucene-queryparser-4.5.0.jar I see these successful results... java SecureLucene Running unsecured... Success! Running with security manager... Success! ...and this unsuccessful result... java SecureLucene true Running with security manager... Exception in thread main java.lang.ExceptionInInitializerError at org.apache.lucene.index.LiveIndexWriterConfig.init(LiveIndexWriterConfig.java:122) at org.apache.lucene.index.IndexWriterConfig.init(IndexWriterConfig.java:165) at SecureLucene$1.run(SecureLucene.java:129) at SecureLucene$1.run(SecureLucene.java:122) at java.security.AccessController.doPrivileged(Native Method) at SecureLucene.getIndexWriter(SecureLucene.java:120) at SecureLucene.runTest(SecureLucene.java:72) at SecureLucene.main(SecureLucene.java:52) Caused by: java.lang.IllegalArgumentException: A SPI class of type org.apache.lucene.codecs.Codec with name 'Lucene45' does not exist. You need to add the corresponding JAR file supporting this SPI to your classpath.The current classpath supports the following names: [] at org.apache.lucene.util.NamedSPILoader.lookup(NamedSPILoader.java:109) at org.apache.lucene.codecs.Codec.forName(Codec.java:95) at org.apache.lucene.codecs.Codec.clinit(Codec.java:122) ... 8 more Classloader issues when running Lucene under a java SecurityManager --- Key: LUCENE-5471 URL: https://issues.apache.org/jira/browse/LUCENE-5471 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.5 Reporter: Rick Hillegas Attachments: SecureLucene.java I see the following error when I run Lucene 4.5.0 under a java SecurityManager. I will attach a test program which shows this problem. The program works fine when a SecurityManager is not installed. But the program fails when I install a SecurityManager. Even more puzzling, the program works if I first run it without a SecurityManager, then install a SecurityManager, then re-run the program, all within the lifetime of a single JVM. I would appreciate advice about how to work around this problem: Exception in thread main java.lang.ExceptionInInitializerError at org.apache.lucene.index.LiveIndexWriterConfig.init(LiveIndexWriterConfig.java:122) at org.apache.lucene.index.IndexWriterConfig.init(IndexWriterConfig.java:165) at SecureLucene$1.run(SecureLucene.java:129) at SecureLucene$1.run(SecureLucene.java:122) at java.security.AccessController.doPrivileged(Native Method) at SecureLucene.getIndexWriter(SecureLucene.java:120) at SecureLucene.runTest(SecureLucene.java:72) at SecureLucene.main(SecureLucene.java:52) Caused by: java.lang.IllegalArgumentException: A SPI class of type org.apache.lucene.codecs.Codec with name 'Lucene45' does not exist. You need to add the corresponding JAR file supporting this SPI to your classpath.The current classpath supports the following names: [] at org.apache.lucene.util.NamedSPILoader.lookup(NamedSPILoader.java:109) at org.apache.lucene.codecs.Codec.forName(Codec.java:95) at org.apache.lucene.codecs.Codec.clinit(Codec.java:122) ... 8 more -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5471) Classloader issues when running Lucene under a java SecurityManager
[ https://issues.apache.org/jira/browse/LUCENE-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912047#comment-13912047 ] Rick Hillegas commented on LUCENE-5471: --- Thanks, Robert. After adding all of those permissions to my policy file, the test runs cleanly. Thanks. Classloader issues when running Lucene under a java SecurityManager --- Key: LUCENE-5471 URL: https://issues.apache.org/jira/browse/LUCENE-5471 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.5 Reporter: Rick Hillegas Attachments: SecureLucene.java I see the following error when I run Lucene 4.5.0 under a java SecurityManager. I will attach a test program which shows this problem. The program works fine when a SecurityManager is not installed. But the program fails when I install a SecurityManager. Even more puzzling, the program works if I first run it without a SecurityManager, then install a SecurityManager, then re-run the program, all within the lifetime of a single JVM. I would appreciate advice about how to work around this problem: Exception in thread main java.lang.ExceptionInInitializerError at org.apache.lucene.index.LiveIndexWriterConfig.init(LiveIndexWriterConfig.java:122) at org.apache.lucene.index.IndexWriterConfig.init(IndexWriterConfig.java:165) at SecureLucene$1.run(SecureLucene.java:129) at SecureLucene$1.run(SecureLucene.java:122) at java.security.AccessController.doPrivileged(Native Method) at SecureLucene.getIndexWriter(SecureLucene.java:120) at SecureLucene.runTest(SecureLucene.java:72) at SecureLucene.main(SecureLucene.java:52) Caused by: java.lang.IllegalArgumentException: A SPI class of type org.apache.lucene.codecs.Codec with name 'Lucene45' does not exist. You need to add the corresponding JAR file supporting this SPI to your classpath.The current classpath supports the following names: [] at org.apache.lucene.util.NamedSPILoader.lookup(NamedSPILoader.java:109) at org.apache.lucene.codecs.Codec.forName(Codec.java:95) at org.apache.lucene.codecs.Codec.clinit(Codec.java:122) ... 8 more -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
