Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug] Docker entrypoint auth bootstrap is unsafe for mounted and upgraded configs

Open
#3,133 5 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, github-actions, java, shell

Research direction

Start with docker-entrypoint.sh and bin/enable-auth.sh to trace the current authentication bootstrap and property rewriting paths. Then inspect the proposed config CLI scope, the entrypoint test suite, and docker-build-ci.yml path filters. Done means mounted and upgraded configurations are handled consistently, secrets are not exposed as process arguments, and the listed shell tests cover the entrypoint contract.

Written by the indexing model from the issue text.

Description

bug improvement

Problem

The Docker entrypoint bootstraps authentication with grep/sed against
conf/rest-server.properties. That works for the shipped defaults it was
written for, but not for mounted configs, upgraded volumes, or any value whose
encoding differs between shell and HugeConfig.

Concrete cases, most of them raised during review of #3119:

  • Gremlin and REST can end up on different auth providers. The check is a
    presence-only grep for auth.authenticator, so a config that already has
    the REST property but not the Gremlin side is treated as fully configured.
  • A pre-existing authenticated volume can fail its first startup after
    upgrade.
    A legacy volume can carry docker/init_complete while the
    bootstrap state the entrypoint now expects is absent.
  • PASSWORD is observable. It is currently handed to Java as a command-line
    argument, which puts it in ps output for every process in the container.
  • sed rewriting does not implement the Java properties grammar. Escaped
    keys, : and whitespace separators, continuations, and duplicate logical
    definitions are all read differently by HugeConfig than by the entrypoint.
    Concretely, set_prop detects only key=, so a mounted config using :
    gets a second logical definition appended and HugeConfig then rejects the
    file as a list. This affects backend and pd.peers as well as
    init_store.enabled, so the fix should cover all of them together.
  • PASSWORD silently does nothing when init-store is skipped. init-store
    reads it from stdin, and the disabled path returns before that, so the admin
    is created on the PD startup path from auth.admin_pa — public default pa.
    #3119 documents this and warns at runtime; it does not fix it.

The first case, as it stands on master 98477f0f5: the entrypoint no longer
greps for auth.authenticator itself, it calls bin/enable-auth.sh whenever
PASSWORD is set, and that script gates only on whether conf-bak/ exists.
On a config it did not write, it appends a second definition to both files,
and the two parsers disagree about which one wins.

A mounted authenticator plus the one enable-auth.sh appends: REST resolves to the first, Gremlin to the last

Proposal

Move property reading and writing off grep/sed and onto the same
Commons Configuration path HugeConfig uses, so both sides agree on encoding,
and let the entrypoint delegate auth classification to it.

Rough shape:

  • a small ConfigTool CLI for typed get/set against a properties file,
    preserving comments, file mode, and inode for mounted configs;
  • entrypoint uses it instead of grep/sed, and stops passing secrets as
    process arguments;
  • auth bootstrap becomes explicit about mounted, upgraded, and custom
    authenticator cases rather than inferring from one key's presence;
  • a shell test suite covering the entrypoint contract, wired into
    docker-build-ci.yml.

Scope

In scope: docker-entrypoint.sh, the new config CLI and its wrapper, the
entrypoint test suite, and the workflow path filters that run it.

Out of scope: the init_store.enabled option and its gate (#3118 / #3119),
Helm chart structure, and GraphManager behavior.

Context

This work originally shared a branch with #3119. That made a ~2,900-line diff
covering two unrelated ideas, so it was split out to keep each reviewable on
its own. #3119 now carries only the option, the gate, the env mapping, and the
init-flag guard.

Visual summary

Docker auth bootstrap

Dominant language
Java
Stars
3.2k
Forks
637
Avg merge
3d 18h
Merged PRs (30d)
23

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/hugegraph

All issues in apache/hugegraph

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.