What causes "User {} can not be added" in apache/hadoop?

Skip wildcard tokens before calling addUser (check token.equals("*"))

apache/hadoop · error · IllegalArgumentException

User {} can not be added

Error message

User {} can not be added

What it means

AccessControlList.addUser throws IllegalArgumentException when the argument is a wildcard ACL value (i.e. "*"). Wildcards only make sense for a whole ACL string (new AccessControlList("*")); they are meaningless as a single entry in the user set, so incremental addition rejects them.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/authorize/AccessControlList.java:154

        aclString.trim().equals(WILDCARD_ACL_VALUE)) {
      return true;
    }
    return false;
  }

  public boolean isAllAllowed() {
    return allAllowed;
  }
  
  /**
   * Add user to the names of users allowed for this service.
   * 
   * @param user
   *          The user name
   */
  public void addUser(String user) {
    if (isWildCardACLValue(user)) {
      throw new IllegalArgumentException("User " + user + " can not be added");
    }
    if (!isAllAllowed()) {
      users.add(user);
    }
  }

  /**
   * Add group to the names of groups allowed for this service.
   * 
   * @param group
   *          The group name
   */
  public void addGroup(String group) {
    if (isWildCardACLValue(group)) {
      throw new IllegalArgumentException("Group " + group + " can not be added");
    }
    if (!isAllAllowed()) {
      List<String> groupsList = new LinkedList<String>();

View on GitHub (pinned to 2add963021)

Solutions

Skip wildcard tokens before calling addUser (check token.equals("*"))
Build wildcard ACLs in one shot with the constructor: new AccessControlList("*") instead of incremental adds
Validate ACL input at the config boundary and reject "*" in lists that will be added entry-by-entry

Example fix

// before
for (String u : usersFromConfig) {
  acl.addUser(u); // throws if u == "*"
}

// after
for (String u : usersFromConfig) {
  if (!"*".equals(u.trim())) {
    acl.addUser(u.trim());
  }
}

Defensive patterns

Strategy: validation

Validate before calling

private static boolean isWildCardAclToken(String s) {
  return s == null || s.trim().isEmpty() || "*".equals(s.trim());
}

for (String u : tokens) {
  if (!isWildCardAclToken(u)) {
    acl.addUser(u.trim());
  }
}

Try / catch

try {
  acl.addUser(user);
} catch (IllegalArgumentException e) {
  // log and reject the offending ACL input, do not silently continue
  throw new ConfigException("Wildcard user token not allowed: " + user, e);
}

Prevention

Prefer building ACLs once from the full string via new AccessControlList(aclString)
Validate policy strings at load time and reject "*" inside token lists
Keep one shared wildcard-check helper for all addUser/addGroup/removeUser/removeGroup call sites

When it happens

Trigger: Calling addUser("*") or feeding tokens split from an ACL string like "* " into addUser; test code using "*" as a placeholder user; config parsers that pass raw ACL fragments to the programmatic API.

Common situations: Code that splits a configured ACL string on whitespace/commas and adds each token; porting XML ACL values into the Java API; sharing one builder for ACLs that are sometimes wildcard.

Related errors

AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/7010f43b51e76dfa. Report an issue: GitHub.