DOKIMASecurity review report

Overview

MakeUserDir creates user home directories with 0777 instead of the configured DirMode (0750)

low Fully Valid high confidence

DOK-100009-FILEBROWSER-SETTINGS-CONFIG-MAKEUSERDIR-CREATE · filebrowser · settings-config

Status

Fully Valid

Confirmed at source: 0777 is used where the configured 0750 DirMode should be, a definite least-privilege violation. Kept fully_valid on the permission defect; severity low because impact needs a multi-user host.

Repository / Component

Repository
filebrowser
Component
settings-config

Plain-English Description

New user folders are created with the most permissive access setting instead of the stricter one the application is configured to use. On a shared machine, other local users could read or change those folders.

Description of the Underlying Issue

settings/dir.go:36 creates each user's home directory with fs.MkdirAll(userScope, os.ModePerm), i.e. mode 0777 (reduced only by the process umask). The configured DirMode (settings/settings.go:17 DefaultDirMode=0750) is applied to Settings but never passed to MakeUserDir. Other directory-creation paths honor DirMode — http/resource.go:134 and writeFile() call MkdirAll with d.settings.DirMode — so MakeUserDir is an inconsistency, not an intentional design choice. This is a least-privilege violation: home directories receive broader permission bits than the operator-configured default.

Potential Attack

On a multi-user host, another OS-level user (not a FileBrowser account) with traversal access to serverRoot navigates into a freshly created user home directory. Because it was created 0777 (typically 0755 after umask 022, but 0777 if the process umask is permissive), that local user can list and, under a permissive umask, write or delete files in another FileBrowser user's home that a 0750 mode would have blocked.

Outcomes of Potential Attack

Unauthorized read (and, under a permissive umask, write/delete) of a FileBrowser user's home-directory contents by other local OS users on the same host. Impact is limited to hosts shared with untrusted local users; FileBrowser's own users remain confined by scope, so this is a defense-in-depth/least-privilege weakness rather than a direct remote compromise.

Affected Scope

settings.MakeUserDir (settings/dir.go:36); every per-user home dir creation path: http/auth.go signup, auth/proxy.go createUser, auth/hook.go SaveUser, http/users.go

Suggested Fix (plain english)

Create user home folders using the same restricted permission setting the rest of the application already uses.

Suggested Fix (detailed)

Replace os.ModePerm with s.DirMode in the settings/dir.go:36 MakeUserDir MkdirAll call so home directories honor the configured (default 0750) mode, matching http/resource.go:134. Verify by creating a user with CreateUserDir enabled and confirming the home directory is created 0750 (subject to umask) rather than 0777. Replace os.ModePerm with s.DirMode in the MakeUserDir MkdirAll call so home dirs honor the configured (0750) mode.

Validation

Confirmed at source: 0777 is used where the configured 0750 DirMode should be, a definite least-privilege violation. Kept fully_valid on the permission defect; severity low because impact needs a multi-user host.

first_opinion

Full Evidence

settings/dir.go:36 fs.MkdirAll(userScope, os.ModePerm) uses 0777
settings/settings.go:17 DefaultDirMode=0750 exists and is applied to Settings but never passed to MakeUserDir
http/resource.go:134 and writeFile() use d.settings.DirMode for MkdirAll, so the codebase honors DirMode elsewhere — MakeUserDir is inconsistent
Proven fact: User home directories are created with os.ModePerm (0777) reduced only by the process umask, instead of the configured DirMode (default 0750)
Proven fact: DirMode is honored on other directory-creation paths, so this is a definite inconsistency, not an intentional design
Unvalidated fact: Actual on-disk mode depends on the runtime umask (0755 under typical umask 022)
Unvalidated fact: Exploitation requires other OS-level users on the host with traversal access to serverRoot; filebrowser's own users remain confined by scope
settings/dir.go:36 — fs.MkdirAll(userScope, os.ModePerm) uses 0777
settings/settings.go:17 — DefaultDirMode=0750 exists and is applied to Settings but never passed to MakeUserDir
http/resource.go:134 and writeFile() — use d.settings.DirMode for MkdirAll, so the codebase honors DirMode elsewhere, making MakeUserDir inconsistent
Proven fact: User home directories are created with os.ModePerm (0777) reduced only by the process umask, instead of the configured DirMode (default 0750).
Proven fact: DirMode is honored on other directory-creation paths, so this is a definite inconsistency rather than intentional design.
Unvalidated fact: Actual on-disk mode depends on the runtime umask (0755 under typical umask 022).
Unvalidated fact: Exploitation requires other OS-level users on the host with traversal access to serverRoot; FileBrowser's own users remain confined by scope.
settings/settings.go:17 DefaultDirMode = 0750 exists and is applied to Settings (settings/storage.go:57-59) but never passed to MakeUserDir
Callers http/users.go, http/auth.go, auth/hook.go create per-user home dirs through this path