0

我正在尝试升级使用嵌入式 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

编辑：尽管我之前安装了安全管理器，但弄清楚为什么会发生异常。事实证明，他们安装了一个策略，该策略使任何不是来自具有以“文件”开头的 url 的代码源的东西都失败。我的应用程序通过 one-jar 加载，因此我所有的代码源都有一个类似的 url：onejar:lib/docopt-0.6.1.jar。因此，当他们尝试安装自己的安全管理器时，他们违反了自己的策略并死了。

4

2 回答 2

1

如果可能的话，您可以确保您现有的安全管理器允许它。也许这样的事情会导致问题，因为它将全局应用于 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);
}

但这可能会在运行时导致问题，所以我会彻底测试它。

于 2017-06-26T19:24:58.527 回答
1

我解决了这样的特殊问题：

  1. 设置我的所有权限策略（确保也覆盖蕴含（））
  2. 临时设置一个忽略检查权限调用的安全管理器（）
  3. Class.forName("org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager") 这会导致类初始化并安装有问题的策略
  4. 再次设置我的所有权限政策
  5. 设置一个普通的 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]
于 2017-06-27T16:24:24.750 回答