Mattermost Server Version

11.10.2

Operating System

Ubuntu 26.04 (and probably any other Unix-like OS)

Steps to reproduce

1. wget https://releases.mattermost.com/11.11.0/mattermost-11.11.0-linux-amd64.tar.gz # current latest
2. tar tvf mattermost-11.11.0-linux-amd64.tar.gz | head

Expected behavior

drwxrwxr-x root/root         0 2026-09-11 08:52 mattermost/
drwxrwxr-x root/root         0 2026-09-11 08:52 mattermost/prepackaged_plugins/
-rw-rw-r-- root/root  32570767 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz
-rw-rw-r-- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz.sig
-rw-rw-r-- root/root  15900090 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz
-rw-rw-r-- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz.sig
-rw-rw-r-- root/root  16578584 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz
-rw-rw-r-- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz.sig
-rw-rw-r-- root/root   9828026 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz
-rw-rw-r-- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz.sig

Observed behavior

drwxrwxrwx root/root         0 2026-09-11 08:52 mattermost/
drwxrwxrwx root/root         0 2026-09-11 08:52 mattermost/prepackaged_plugins/
-rw-rw-rw- root/root  32570767 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz
-rw-rw-rw- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz.sig
-rw-rw-rw- root/root  15900090 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz
-rw-rw-rw- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz.sig
-rw-rw-rw- root/root  16578584 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz
-rw-rw-rw- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz.sig
-rw-rw-rw- root/root   9828026 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz
-rw-rw-rw- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz.sig

Additional Information

The installation instructions suggest extracting the files as non-root, which will result in the user’s umask being applied to the output files, so that’ll cause the world-writablity bit to get dropped (hopefully for most users).

It’d still be better though if the files were 0660/0770 (or at least 0664/0775) even when extracted as root. (Group-writability is enforced by the instructions’ sudo chmod -R g+w /opt/mattermost in any case.)

But how does the latter scenario differ from one where `mktemp` is invoked without `-u`? Even if the file is created (as opposed to just the name), nothing prevents another process from writing to the same file once it has been created.

Preventing ownership changes is not a filesystem/Access Control Lists feature, it’s a UNIX feature designed to prevent bad things from happening.

I suppose you could give the wordpress user the permission to chown via sudoers if you really wanted to, but I would question the reasons for trying to do this in the first place.

Since you appreciate typo spotting, a couple of more it’ses to itses: ConsoleKit and its successor, to retain its position.

This was very interesting to read, thank you. I wish more people could see these issues as resulting from conflicting design philosophies and would put their effort on improving implementations of their choice, rather than arguing that the other choice is inferior (let alone those ad hominem attacks against the other camp). I for one believe both designs have their uses, and that we shouldn’t be advocating either as the be-all end-all.

From a similar question on ServerFault (and particularly one response there), one possible explanation for the disparity is that there are processes hanging on to files they’ve accessed on /tmp that have since been deleted.

# lsof | grep deleted 

will list such files along with the processes still attached to them.

According to a Xiph mailing list message from 2003,

ogginfo should check most things, at least the CRC integrity of everything.

I don’t know whether ogginfo is available for Windows though. You’d also have to script the recursion part, as ogginfo doesn’t do that (at least on UNIX).