嵌入Cassandra-安全管理器问题 [英] Embedding Cassandra - Security Manager issues

问题描述

我正在尝试升级使用嵌入式cassandra 2.1.1的应用程序(大约是时间！)，但是有问题的应用程序设置了它自己的安全管理器. Cassandra 3.11似乎没有考虑这种可能性，只是尝试自行设置安全管理器，而没有考虑可能已经存在(失败).

I am attempting to upgrade an application that uses an embedded cassandra 2.1.1 (about time!), but the application in question sets it's own security manager. Cassandra 3.11 seems to not consider this possibility and just attempts to set the security manager on it's own without any consideration that there might already be one (which fails).

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代码时，似乎没有任何配置检查可以避免这种情况:

There doesn't seem to be any check for configuration to avoid this when I browse the Cassandra code:

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

ThreadAwareSecurityManager中的注释似乎表明这是为了使用户定义的函数安全，但是我没有使用用户定义的函数的计划，因此我很乐意将其关闭，但我看不到这样的说法.代码中的一个选项.

Comments in ThreadAwareSecurityManager seem to indicate that this is meant to make user defined functions safe, but I have no plans to use user defined functions, so I'd be perfectly happy to turn that off, but I don't see such an option in the code.

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进行代码更改才能生效.有谁有更好的主意吗?

This looks suspiciously like it requires a code change to Cassandra before it will ever work. Does anyone have a better idea?

作为参考，这是为了逃避旧cqlsh在当前版本的python中遇到的问题:

For reference, this comes about as an attempt to escape issues that old cqlsh has with current versions of python:

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

编辑:弄清楚了为什么尽管我先前安装了安全管理器，但还是发生了异常.事实证明，他们安装了一个策略，该策略会使所有非源于以"file"开头的url的代码源失败.我的应用程序通过一个jar加载，因此我所有的代码源都具有一个URL，例如:onejar:lib/docopt-0.6.1.jar.因此，当他们尝试安装自己的安全管理器时，就会违反自己的策略而死.

Figured out why the exception occurs despite my previous installation of security manager. It turns out that they install a policy that fails anything not coming from a codesource with a url starting with 'file'. My app loads via one-jar so all my code sources have a url like: onejar:lib/docopt-0.6.1.jar. Thus when they try to install their own security manager, they run afoul of their own policy and die.

推荐答案

我克服了像这样的特殊问题:

I got past this particular problem like this:

1. 设置我的所有权限策略(确保还覆盖implies())
2. 临时设置一个安全管理器，该管理器将忽略用于检查Permission()的调用
3. Class.forName("org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager")导致类初始化并安装有问题的策略
4. 再次设置我的所有烫发政策
5. 设置普通的SecurityManager()

1. Set my all perms policy (making sure to also override implies())
2. Temporarily set a security manager that ignores calls to check permission()
3. Class.forName("org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager") Which causes the class to initialize and install the offending policy
4. Set my all perms policy again
5. Set a vanilla SecurityManager()

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

这防止了上面的堆栈跟踪，并导致了另一个问题，因此，我将在此处结束此问题，并在需要时打开另一个问题，但是作为参考，下一个问题仍然与ThreadAwareSecurityManager有关...

This prevents the above stack trace, and leads to a different problem, so I'll end this question here, and open another if needed, but for reference the next problem is still related to 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-安全管理器问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！