Some question to permissions, owner etc. TP Version 3.2.x

[Sky-W-ui]

I upgraded my test system from 3.1.7.6 to 3.2.x
After reading the documentation and upgrading according documentation I got some confusion regarding permission, owner and group for the folder "public"
According to documentation the folder has the owner (for me www-data) and group (also www-data).
And perms with chmod is 755

But it shouldnt be writable by webserver.

So now i am a bit confused. What is the right configuration for the folder?
With the configuration 755 an owner www-data the webserver can write in the folder?

Hopefully you guys can resolve this confusion for me.
Regards
Sky

[nilsteampassnet]

Hi @Sky-W-ui, good catch, this is a legitimate source of confusion, so let me clarify.

Short answer: with 755 and owner www-data, yes, the web server can write to the folder. 755 means owner = rwx, group = r-x, others = r-x. Since www-data (the web server) is the owner, it gets the rwx bits. That's exactly why the upgrade wizard raises the "should not be writable" warning: in that ownership setup, public/ (and app/) really are writable by the web server. The check behind it is a plain is_writable(), which returns true whenever the PHP process can write — owner-write counts.

There are two valid permission models, and the docs unfortunately mixed them (I'm fixing that):

1. Simple model - everything owned by www-data:www-data, 755/644

• Easiest to set up, works fine functionally.
• Downside: app/ and public/ end up writable by the web server → the wizard shows a non-blocking warning. The upgrade still proceeds; it's a hardening recommendation, not an error.
• Note: in this model, chmod 0755 will not clear the warning, because owner-write is still there. You'd have to remove owner-write on the two folders (they aren't written at runtime, only during an upgrade) and restore it before the next upgrade.

2. Hardened model (recommended) - split owner
Own the code with an account that is not the web server user (a dedicated non-login account, or simply root), and give the web server only group access:

owner : root (or a dedicated "teampass" account) → not the web server
group : www-data                                 → the web server process

TEAMPASS=/var/www/html/teampass

# Code: readable by the web server, NOT writable
sudo chown -R root:www-data ${TEAMPASS}/app ${TEAMPASS}/public
sudo find ${TEAMPASS}/app    -type d -exec chmod 0755 {} \;
sudo find ${TEAMPASS}/app    -type f -exec chmod 0644 {} \;
sudo find ${TEAMPASS}/public -type d -exec chmod 0755 {} \;
sudo find ${TEAMPASS}/public -type f -exec chmod 0644 {} \;

# Runtime dirs the web server must write to → group-writable, group = www-data
sudo chown -R root:www-data ${TEAMPASS}/storage \
    ${TEAMPASS}/public/assets/avatars \
    ${TEAMPASS}/app/includes/libraries/csrfp/log
sudo find ${TEAMPASS}/storage -type d -exec chmod 2770 {} \;
sudo chmod 2770 ${TEAMPASS}/public/assets/avatars ${TEAMPASS}/app/includes/libraries/csrfp/log

Here the web server is only in the group for app//public/, so it has r-x = read-only → the "should not be writable" warning clears — and it can still write to storage/, avatars and the CSRF log via the group bit.

Reminder: app/config/ and app/includes/libraries/csrfp/libs/ must be writable during an upgrade (they hold settings.php / the CSRF config). Make them group-writable (chmod 2770, group www-data) for the upgrade, or lock them again afterwards as described in the docs.

Bottom line: the warning is informational / non-blocking. If you want it gone and want proper defense-in-depth (a compromised PHP process can't rewrite its own code), use the split-owner model above.

Thanks for reporting this, the permissions doc and the wizard's suggested fix were misleading on exactly this point, and both will be corrected in an upcoming release.

[Sky-W-ui]

Thanks for the clarification :)

[Sky-W-ui]

I have another question to permissions.
In the documentation i have the following for the secretkey-file

it says it need the rights 600 (read-write for owner) but it says it should be read only owner.
So which column is wrong. Should the owner read-write or the permission 400?

And another thing you have in https://documentation.teampass.net/#/install/file-permissions under "verification checklist" a script to check the permissions of some key folders and files. It works fine by me except the last command.

With this command he finds symlinks under public/includes/language that have the 777 permission and because they are symlinks you cant change the permission for the links. So every time i run the script i get these entries under the last command where i shouldnt get any output at all. If these symlinks are intentionally then use this so that the script doesnt check the public language folder.
find ${TEAMPASS} -not \( -path "*/vendor/*" -o -path "${TEAMPASS}/public/includes/language/*" \) -perm -o+w -ls

[nilsteampassnet]

Hi @Sky-W-ui, thanks again for the careful reading, you found two documentation bugs, both real.

1. Encryption key file: 0600 vs 0400

The mode is right, the wording is wrong. "read-only owner" was meant as "readable only by the owner" (nothing for group, nothing for others), not "read-only". 0600 = rw-------. The Notes column will be reworded to "Owner read/write — no access for group or others".

Would 0400 work? At runtime, yes.
Teampass only reads the key file (file_get_contents() in sources/main.functions.php and in SessionManager); it never rewrites it after installation. So 0400 is harmless in steady state.

But it buys you almost nothing as long as the file's owner is the web server user: the owner can chmod the file back to rw whenever it wants, so 0400 is not a boundary against the very process you are trying to constrain.
What actually protects the key is the group/other bits being 0, plus 0750 on secrets/ so the directory cannot even be listed.

If you want real defense-in-depth here, apply the same split-owner logic as for app/ and public/:

TEAMPASS=/var/www/html/teampass
SECKEY=$(grep -oP 'define\("SECUREFILE",\s*"\K[^"]+' ${TEAMPASS}/app/config/settings.php)

sudo chown root:www-data ${TEAMPASS}/secrets ${TEAMPASS}/secrets/${SECKEY}
sudo chmod 0750 ${TEAMPASS}/secrets            # www-data: r-x → can read the key, cannot create/rename/delete in it
sudo chmod 0640 ${TEAMPASS}/secrets/${SECKEY}  # www-data: read only, and cannot chmod it (not the owner)

That is strictly stronger than 0400 www-data:www-data: PHP can read the key but can neither rewrite it nor replace it. Just remember to grant write back temporarily if you ever re-run the installer, key creation (installer) and the legacy teampass-seckey.txt copy/rename handled by the upgrade wizard need write access on the secrets/ directory.

Bonus, same section: on a 3.x install the key file is not named teampass-seckey.txt. The installer generates a random file name and stores it in SECUREFILE in app/config/settings.php, so this checklist line only works on installs that came from older versions:

# instead of: stat -c "%a %n" ${TEAMPASS}/secrets/teampass-seckey.txt
SECKEY=$(grep -oP 'define\("SECUREFILE",\s*"\K[^"]+' ${TEAMPASS}/app/config/settings.php)
stat -c "%a %n" ${TEAMPASS}/secrets/${SECKEY}

2. World-writable check and the language symlinks

Confirmed and yes, those symlinks are intentional. public/includes/language/datatables..txt (21 files) are symlinks to app/includes/language/datatables..txt: DataTables fetches its i18n file over HTTP, so it must be reachable under the webroot, while the actual file stays in app/.

Their lrwxrwxrwx is normal and harmless: on Linux a symlink's own permission bits are always 0777 and are never used for access control, the kernel checks the permissions of the target. chmod follows the link, so you cannot change them (and there is nothing to fix).

Your workaround works.
I'd rather skip symlinks than skip a directory, so the check keeps auditing real files in that folder and covers any symlink added elsewhere later:

find ${TEAMPASS} -not -path "*/vendor/*" ! -type l -perm -o+w -ls

Both corrections (the wording, the stat line and the find line) will land in docs/install/file-permissions.md for the next release.
Thanks!