[Feat]: Group read access to local storage files

[shoneefd]

Is your feature request related to a problem? Please describe.

I'm running zot on a bare metal server with local storage. I store the containers in /storage/zot. Here's a snapshot of what that directory's contents look like:

drwxr-xr-x  3 zot zot    4096 Dec 22 01:38 ..
-rw-------  1 zot zot 4194304 Mar 15 17:17 cache.db
-rw-------  1 zot zot 2097152 Mar 15 17:17 meta.db
-rw-------  1 zot zot 2097152 Mar 15 16:45 repo.db
drwx------  3 zot zot    4096 Feb 27 19:30 container-folder-1
drwx------ 76 zot zot    4096 Mar 19 19:17 container-folder-2
drwx------  2 zot zot    4096 Dec 22 01:39 _sessions

As you can see, all items within the directory are stored with 700 access permissions. However, I have a particular use case that would really benefit from giving read-only access to another user on the local machine. Ideally, I'd like to configure zot to store all files with 740 permissions, so that I can create another user within the zot group which has only read access to those files. However, I can't find any way in the documentation to configure zot to do that.

For reference, here is what my config file looks like:

  "distSpecVersion": "1.1.0-dev",
  "storage": {
    "rootDirectory": "/storage/zot",
    "dedupe": "true",
    "gc": "true",
    "gcDelay": "1h",
    "gcInterval": "24h"
  },
  "http": {
    "address": "<host_ip>",
    "port": "<http_port>",
    "realm": "<realm_name>",
    "tls": {
      "cert": "/etc/opt/zot/fullchain.pem",
      "key": "/etc/opt/zot/privkey.pem"
    },
    "Ratelimit": {
      "Rate": 10,
      "Methods": [
        {
          "Method": "GET",
          "Rate": 5
        }
      ]
    },
    "auth": {
      "failDelay": 5,
      "bearer": {
        "realm": "<token_auth_url>",
        "service": "<server_host_name>",
        "cert": "/etc/zot/auth.crt"
      },
      "htpasswd": {
        "path": "/etc/zot/htpasswd"
      }
    }
  },
  "log": {
    "level": "info",
    "output": "/var/log/zot/zot.log",
    "audit": "/var/log/zot/zot-audit.log"
  },
  "extensions": {
    "metrics": {
      "enable": true,
      "prometheus": {
        "path": "/metrics"
      }
    },
    "lint": {
      "enable": false
    },
    "scrub": {
      "enable": false
    },
    "search": {
      "enable": false
    },
    "sync": {
      "enable": false
    },
    "trust": {
      "enable": false
    },
    "ui": {
      "enable": false
    }
  }
}

Describe the solution you'd like

A way to, through the zot config.json, configure zot to store files with the file access permissions of my choice, particularly 740, 744, and 764.

Describe alternatives you've considered

Using ACLs to manually configure an additional layer of file access permissions, or using a custom systemd service or script to manually change the permissions of all files within /storage/zot either periodically or whenever a change in the directory is detected.

Both of these options are a lot of hassle and maintenance for relatively little return. The security benefits of this permissions change, while non-zero, are not large. For now, I am simply using the zot user itself to perform the read operations I need.

Additional context

I initially assumed this was already a feature within zot, but was unable to find documentation anywhere on zotregistry.dev, and searching through the codebase yielded no results. If I missed something, I'd appreciate being pointed in the right direction!

[rchincha]

@shoneefd it is in general race-prone to read this layout directly since zot process may be updating contents. The best option is to read over the HTTP interface and zot has a reasonably powerful authN/Z support.

In any case, could you elaborate on your use case, maybe we are not appreciating it fully.

[shoneefd]

@rchincha Our particular use case involves a secondary server using rsync to back up the files stored in our primary registry. Ideally, I'd want that rsync command to ssh into a user with read-only access to the registry storage.

I believe zot is meant to have other ways to fulfill our data backup needs through the sync plugin, but unfortunately that functionality for our particular use is currently blocked by this bug.

[eusebiu-constantin-petu-dbk]

Hello @shoneefd

That sync bearer auth issue is fixed #2212
Sorry, forgot to update @2149 too.

Can you try it please?

[shoneefd]

Hey @peusebiu, I can confirm this works! Sorry for the delay in testing, I'm closing this issue now.