Skip to content

perf: avoid unconditional chmod -R in enforce_misp_data_permissions#378

Open
LSI-ZuagrastaWastl wants to merge 1 commit intoMISP:masterfrom
LSI-Bayern:master
Open

perf: avoid unconditional chmod -R in enforce_misp_data_permissions#378
LSI-ZuagrastaWastl wants to merge 1 commit intoMISP:masterfrom
LSI-Bayern:master

Conversation

@LSI-ZuagrastaWastl
Copy link

Problem

enforce_misp_data_permissions() in entrypoint_nginx.sh ends each permission block with an unconditional chmod -R u+w,g+w over app/files and app/tmp. On deployments with large numbers of attachments or events, this causes significant startup delays on every docker compose up, even when permissions are already correct.
see Issue: #377

Two additional issues exist in the same function:

  • -not -perm 550 and -not -perm 770 without a leading / are interpreted as exact octal matches by find, not as bitmask checks. This means files that already have more bits set (e.g. 0750) are unnecessarily chmod'd every run.
  • chmod -R u+w,g+w <dir> traverses and syscalls every single file, regardless of whether any permission bit is actually wrong.

Fix

Replace the three unconditional chmod -R calls with targeted find expressions that only touch files whose permissions are actually incorrect:

-find /var/www/MISP/app/tmp -not -perm 550  -type f -exec chmod 0550 {} +
-find /var/www/MISP/app/tmp -not -perm 770  -type d -exec chmod 0770 {} +
-chmod -R u+w,g+w /var/www/MISP/app/tmp
+find /var/www/MISP/app/tmp -not -perm /0550 -type f -exec chmod 0550 {} +
+find /var/www/MISP/app/tmp -not -perm /0770 -type d -exec chmod 0770 {} +
+find /var/www/MISP/app/tmp \( ! -perm -u+w -o ! -perm -g+w \) -exec chmod u+w,g+w {} +

-find /var/www/MISP/app/files -not -perm 550  -type f -exec chmod 0550 {} +
-find /var/www/MISP/app/files -not -perm 770  -type d -exec chmod 0770 {} +
-chmod -R u+w,g+w /var/www/MISP/app/files
+find /var/www/MISP/app/files -not -perm /0550 -type f -exec chmod 0550 {} +
+find /var/www/MISP/app/files -not -perm /0770 -type d -exec chmod 0770 {} +
+find /var/www/MISP/app/files \( ! -perm -u+w -o ! -perm -g+w \) -exec chmod u+w,g+w {} +

-find /var/www/MISP/app/Config -not -perm 550  -type f -exec chmod 0550 {} +
-find /var/www/MISP/app/Config -not -perm 770  -type d -exec chmod 0770 {} +
+find /var/www/MISP/app/Config -not -perm /0550 -type f -exec chmod 0550 {} +
+find /var/www/MISP/app/Config -not -perm /0770 -type d -exec chmod 0770 {} +

Why -perm /0550 instead of -perm 0550

From man find:

-perm mode — matches files with exactly these permission bits set.
-perm /mode — matches files that have any of these permission bits set (bitmask).
-perm -mode — matches files that have all of these bits set.

-not -perm 0550 would re-chmod any file with mode 0750, 0555, 0755, etc. — i.e. files that already have equal or broader permissions — which is incorrect. -not -perm /0550 correctly skips files that already satisfy the minimum required bits.

Impact

  • First start / after MISP version update: behaviour is identical — all files are visited and permissions corrected.
  • Subsequent compose up (steady state): the find filter short-circuits immediately for every file that already has correct permissions, reducing the number of chmod syscalls from all files to files with wrong permissions, which in a stable deployment is ~0.
  • Deployments with thousands of event attachments (common in production) will see startup time drop from minutes to seconds on repeated compose up.

Testing

Tested on a deployment with ~80GB files in app/files. Startup permission phase went from ~5-10 minutes to under 1 minute on the second compose up.

…are actually incorrect

Replace the three unconditional `chmod -R` calls with targeted `find` expressions that only touch files whose permissions are actually incorrect.
@ostefano
Copy link
Collaborator

Wow TIL.

Will test and merge it at the next opportunity.

LGTM, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants