Dgraph 1.2.6 accepts backup regardless of ACL or auth-token setting

Issues Dgraph
, ,
1

Report a Dgraph Bug

When running Dgraph 1.2.6 with both --auth_token string and --acl_secret_file configured, making requests to /admin/backup with be accepted without either a access-token or auth-token:

$ /usr/bin/curl --silent -\
  -request POST 'localhost:8080/admin/backup?force_full=false' \
  --data 'destination=minio://backgcs-gateway:9000/joaquin-dgraph-backups/dgraph_20200906?secure=false'
{"code": "Success", "message": "Backup completed."}

What version of Dgraph are you using?

v.1.2.6

Have you tried reproducing the issue with the latest release?

Yes, but with GraphQL /admin request instead of /admin/backup

What is the hardware spec (RAM, OS)?

  • Docker container: 20.04 LTS (Focal Fossa)
  • Host System: Pop!_OS (Ubuntu 19.10)

Steps to reproduce the issue (command/config used to run Dgraph).

  1. Start Dgraph Alpha with ACL and AuthToken configured (see docker-compose.yaml and acl_auth_config.hcl)
  2. Trigger a Backup through /admin/backup (see command)

acl_auth_config.hcl

whitelist       = "10.0.0.0/8,192.168.0.0/16,172.16.0.0/12,172.20.0.0/12"
acl_secret_file = "/dgraph/acl/hmac_secret_file"
auth_token      = "6jtXKSTL9vz5KPg"

docker-compose.yaml

services:
  backgcs-alpha1:
    command: dgraph alpha --my=backgcs-alpha1:7080 --lru_mb=1024 --zero=backgcs-zero1:5080
      --config /dgraph/config/acl_auth_config.hcl
    container_name: backgcs-alpha1
    image: dgraph/dgraph:v1.2.6
    ports:
    - published: 8080
      target: 8080
    - published: 9080
      target: 9080
    volumes:
    - read_only: true
      source: ./acl
      target: /dgraph/acl/
      type: bind
    - read_only: true
      source: ./config
      target: /dgraph/config
      type: bind
    working_dir: /data/alpha1

  backgcs-zero1:
    command: dgraph zero --my=backgcs-zero1:5080 --replicas 1 --idx 1
    container_name: backgcs-zero1
    image: dgraph/dgraph:v1.2.6
    ports:
    - published: 5080
      target: 5080
    - published: 6080
      target: 6080
    working_dir: /data/zero1
version: '3.5'

command

 /usr/bin/curl --silent -\
  -request POST 'localhost:8080/admin/backup?force_full=false' \
  --data 'destination=minio://backgcs-gateway:9000/joaquin-dgraph-backups/dgraph_20200906?secure=false'

Expected behavior and actual result.

I expected that I would have to supply an auth-token and an accessJWT token to be able to interact with /admin/backup route, as this is the behavior with v20.03.4. With both v20.03.4 and v20.07.0 the accessJWT is absolutely required for backups.

The documentation is ambiguous in this area, as it does not document the exact routes where ACLs are applied, whether or not they are required with backups, and scenario if both auth-token and accessJWT are used together. Further, documentation only documents to v1.2.2 and earlier for the 1.x versions.

The actual results are:

{
  "code": "Success",
  "message": "Backup completed."
}