Question

我正在尝试升级使用嵌入式cassandra 2.1.1的应用程序（关于时间！），但是有问题的应用程序设置了它自己的安全管理器。 Cassandra 3.11似乎没有考虑这种可能性，只是尝试在它自己设置安全管理器而不考虑可能已经有一个（失败）。

2017-06-26T12:05:22,736 ERROR Thread-0 org.apache.cassandra.service.CassandraDaemon Exception encountered during startup
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "createSecurityManager")
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) ~[?:1.8.0_101]
    at java.security.AccessController.checkPermission(AccessController.java:884) ~[?:1.8.0_101]
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) ~[?:1.8.0_101]
    at java.lang.SecurityManager.<init>(SecurityManager.java:299) ~[?:1.8.0_101]
    at org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager.<init>(ThreadAwareSecurityManager.java:199) ~[?:3.11.0]
    at org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager.install(ThreadAwareSecurityManager.java:80) ~[?:3.11.0]
    at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:192) ~[?:3.11.0]
    at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600) ~[?:3.11.0]
    at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:94) ~[?:?]
    at org.jesterj.ingest.Main.startCassandra(Main.java:190) ~[?:?]
    at org.jesterj.ingest.Main.lambda$main$0(Main.java:125) ~[?:?]
    at java.lang.Thread.run(Thread.java:745) [?:1.8.0_101]

当我浏览Cassandra代码时，似乎没有检查配置以避免这种情况：

public static void install()
{
    if (installed)
        return;
    System.setSecurityManager(new ThreadAwareSecurityManager());

ThreadAwareSecurityManager中的注释似乎表明这是为了使用户定义的函数安全，但我没有计划使用用户定义的函数，所以我非常乐意将其关闭，但我没有看到这样的代码中的一个选项。

static
{
    //
    // Use own security policy to be easier (and faster) since the C* has no fine grained permissions.
    // Either code has access to everything or code has access to nothing (UDFs).
    // This also removes the burden to maintain and configure policy files for production, unit tests etc.

这看起来很可疑，因为它需要在Cassandra运行之前对其进行代码更改。有没有人有更好的主意？

作为参考，这是为了逃避旧cqlsh与当前版本的python有关的问题：

https://github.com/nsoft/jesterj/issues/89

编辑：尽管我之前安装了安全管理器，但想出了为什么会发生异常。事实证明，他们安装了一个策略，该策略无法通过带有以'file'开头的url的codesource来实现。我的应用程序通过one-jar加载，所以我的所有代码源都有一个url：onejar：lib / docopt-0.6.1.jar。因此，当他们试图安装自己的安全管理器时，他们会违反自己的政策而死亡。

Answer 1

如果可能，您可以确保现有的安全管理器允许它。也许像this之类的东西会导致问题，因为它将全局应用于JVM。

或者你可以跳过它...它是一个更糟糕的选择，它可能会破坏你的东西，但你可以使用反射。

(inside whatever main class or something loaded very early in application)

static {
        Field installed = ThreadAwareSecurityManager.class.getField("installed");
        installed.setAccessible(true);
        installed.set(null, true);
}

但这可能会导致运行时出现问题，因此我会对其进行彻底的测试。

Answer 2

我遇到了这个特殊的问题：

设置我的所有perms策略（确保也覆盖implies（））
暂时设置一个忽略对check permission（）
Class.forName("org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager")这会导致课程初始化并安装违规政策
再次设置我的所有权限政策
设置一个vanilla SecurityManager（）

这是提交：https://github.com/nsoft/jesterj/commit/37c0206eac144e9076600f64bb298039212058f5#diff-6bdddcc8f3676796dbad2f7b694fa7fcL268

这可以防止上面的堆栈跟踪，并导致一个不同的问题，所以我将在这里结束这个问题，并在需要时打开另一个问题，但作为参考，下一个问题仍然与ThreadAwareSecurityManager有关...

java.lang.ClassCastException: org.apache.logging.slf4j.Log4jLogger cannot be cast to ch.qos.logback.classic.Logger
    at org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager.install(ThreadAwareSecurityManager.java:92) ~[cassandra-all-3.11.0.jar:3.11.0]
    at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:192) ~[cassandra-all-3.11.0.jar:3.11.0]
    at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600) ~[cassandra-all-3.11.0.jar:3.11.0]
    at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:94) ~[main.jar:?]
    at org.jesterj.ingest.Main.startCassandra(Main.java:198) ~[main.jar:?]
    at org.jesterj.ingest.Main.lambda$main$0(Main.java:132) ~[main.jar:?]
    at java.lang.Thread.run(Thread.java:745) [?:1.8.0_101]

嵌入Cassandra - 安全管理器问题

2 个答案: