apache/cassandra · error · AccessControlException

access denied: + MODIFY_THREADGROUP_PERMISSION

Error message

access denied: + MODIFY_THREADGROUP_PERMISSION

What it means

ThreadAwareSecurityManager overrides checkAccess(ThreadGroup) because the default SecurityManager only enforces the modifyThreadGroup permission for threads in the root thread group. When the current thread is a secured UDF thread attempting to access or modify a thread group, this override throws AccessControlException for modifyThreadGroupPermission to keep UDF code sandboxed.

Source

Thrown at src/java/org/apache/cassandra/security/ThreadAwareSecurityManager.java:204

    }

    public void checkAccess(Thread t)
    {
        // need to override since the default implementation only checks the permission if the current thread's
        // in the root-thread-group

        if (isSecuredThread())
            throw new AccessControlException("access denied: " + MODIFY_THREAD_PERMISSION, MODIFY_THREAD_PERMISSION);
        super.checkAccess(t);
    }

    public void checkAccess(ThreadGroup g)
    {
        // need to override since the default implementation only checks the permission if the current thread's
        // in the root-thread-group

        if (isSecuredThread())
            throw new AccessControlException("access denied: " + MODIFY_THREADGROUP_PERMISSION, MODIFY_THREADGROUP_PERMISSION);
        super.checkAccess(g);
    }

    public void checkPermission(Permission perm)
    {
        if (!DatabaseDescriptor.enableUserDefinedFunctionsThreads() && !DatabaseDescriptor.allowExtraInsecureUDFs() && SET_SECURITY_MANAGER_PERMISSION.equals(perm))
            throw new AccessControlException("Access denied");

        if (!isSecuredThread())
            return;

        // required by JavaDriver 2.2.0-rc3 and 3.0.0-a2 or newer
        // code in com.datastax.driver.core.CodecUtils uses Guava stuff, which in turns requires this permission
        // TODO: Evaluate removing this once the driver is removed as a dependency (see CASSANDRA-20326).
        if (CHECK_MEMBER_ACCESS_PERMISSION.equals(perm))
            return;

        // Nashorn / Java 11

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Remove thread-group access/manipulation from the UDF; keep UDFs side-effect free.
  2. Move the thread-group logic out of the UDF into normal application code (e.g. the client submitting queries).
  3. Refactor the UDF to return data and let external code manage threads.
  4. Only if explicitly accepted as insecure, consider allow_extra_insecure_udFs / related settings — this weakens the sandbox and is discouraged.

Example fix

// before (inside a UDF)
Thread.currentThread().getThreadGroup().interrupt();

// after
return result; // manage thread groups outside UDF execution
Defensive patterns

Strategy: try-catch

Try / catch

try {
    threadGroup.checkAccess();
} catch (AccessControlException e) {
    logger.warn("ThreadGroup access denied in sandboxed UDF context: {}", e.getMessage());
    throw new UnsupportedOperationException("ThreadGroup manipulation is not permitted inside UDFs");
}

Prevention

When it happens

Trigger: Code running inside a Cassandra UDF (secured thread) calls ThreadGroup methods requiring access checks — e.g. enumerating, interrupting, stopping, or setting max priority on a thread group — while the security manager is active.

Common situations: UDFs that inspect or manipulate thread groups for coordination or cleanup; ported library code used in UDFs that assumes unrestricted thread-group access; experimenting with concurrency inside sandboxed UDFs.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors


AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/d02023b4558a68de. Report an issue: GitHub.