[team edition] incorrect default securityContext

[clouedoc]

I am encountering permission issues when trying to install a plugin from the /marketplace
Additionally, default plugins couldn't install themselves.

Impact

This causes 30min of unnecessary debugging to new users of the team edition.

Root cause

The volumes are mounted with incorrect permissions; thus, the app cannot execute the operations necessary to installing a plugin (mkdir, copy).

Troubleshooting details

Logs

{"timestamp":"2023-07-13 17:43:57.979 Z","level":"error","msg":"Unable to activate plugin","caller":"app/plugin.go:171","plugin_id":"playbooks","error":"unable to generate webapp bundle: playbooks: unable to copy webapp bundle directory: playbooks: mkdir client/plugins/playbooks: permission denied"}
{"timestamp":"2023-07-13 17:43:57.979 Z","level":"error","msg":"Unable to activate plugin","caller":"app/plugin.go:171","plugin_id":"focalboard","error":"unable to generate webapp bundle: focalboard: unable to copy webapp bundle directory: focalboard: mkdir client/plugins/focalboard: permission denied"}

Reproduction Helm configuration

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: mattermost
  namespace: argocd
spec:
  project: default
  source:
    chart: mattermost-team-edition
    repoURL: https://helm.mattermost.com
    targetRevision: 6.6.30
    helm:
      releaseName: mattermost
      values: |
        mysql:
          mysqlUser: XXXXXXXXXXXXXXXXXXXX
          mysqlPassword: XXXXXXXXXXXXXXXXXXXXXXXXXXXX

        configJSON:
          ServiceSettings:
            SiteURL: "http://mattermost.infra.svc.cluster.local"
          TeamSettings:
            SiteName: "XXXXXXXXXXXXXXXXXXXX"

        service:
          type: ClusterIP
          externalPort: 80
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: infra

Permissions inside the container

mattermost@mattermost-mattermost-team-edition-746df76b69-bs7nw:~$ ls -lah
total 288K
drwxr-xr-x 1 mattermost mattermost 4.0K Jul  5 09:40 .
drwxr-xr-x 1 root       root       4.0K Jul 13 17:42 ..
-rw-r--r-- 1 mattermost mattermost 1.3K Jul  5 09:40 MIT-COMPILED-LICENSE.md
-rw-r--r-- 1 mattermost mattermost 214K Jul  5 09:40 NOTICE.txt
-rw-r--r-- 1 mattermost mattermost 7.0K Jul  5 09:40 README.md
drwxr-xr-x 2 mattermost mattermost 4.0K Jul  5 09:41 bin
drwxr-xr-x 1 mattermost mattermost 4.0K Jul  5 09:40 client
drwxrwxrwx 2 root       root       4.0K Jul 13 17:41 config
drwxr-xr-x 3 root       root       4.0K Jul 13 17:41 data
drwxr-xr-x 2 mattermost mattermost 4.0K Jul  5 09:40 fonts
drwxr-xr-x 2 mattermost mattermost 4.0K Jul  5 09:40 i18n
drwxr-xr-x 2 mattermost mattermost 4.0K Jul 13 17:42 logs
-rw-r--r-- 1 mattermost mattermost  632 Jul  5 09:40 manifest.txt
drwxr-xr-x 8 mattermost mattermost 4.0K Jul 13 17:54 plugins
drwxr-xr-x 2 mattermost mattermost 4.0K Jul  5 09:41 prepackaged_plugins
drwxr-xr-x 2 mattermost mattermost 4.0K Jul  5 09:40 templates
mattermost@mattermost-mattermost-team-edition-746df76b69-bs7nw:~$

config and data are owned by root:root instead of mattermost:mattermost
client/plugins is owned by root:root instead of mattermost:mattermost

Fixing existing deployments

Adding the following lines to the values.yaml mounts the volumes with the correct permissions:

securityContext:
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch"

Using extraInitContainers as detailed in #120 also seems to be a viable option.

Fixing future deployments

The securityContext above should be used by default in the Helm chart.

[clouedoc]

Looks related to #120

[clouedoc]

There are three volumes to potentially chown:

uid and gid should be 2000

mattermost@mattermost-mattermost-team-edition-746df76b69-bs7nw:~$ id
uid=2000(mattermost) gid=2000(mattermost) groups=2000(mattermost)

[clouedoc]

I believe there are two ways to accomplish what I want:

• tweaking the securityContext
• running extraInitContainers

[clouedoc]

Tweaking the securityContext was enough.

Here is the additional configuration that needs to be added to resolve this issue:

securityContext:
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch"