In‑Depth Analysis of JuiceFS Permission Management: Full Compatibility with Linux Security Mechanisms

01 Access Control Models: DAC and MAC

Linux file‑access control uses two primary models. Discretionary Access Control (DAC) lets owners set permissions (Unix Permission, POSIX ACL). Mandatory Access Control (MAC) enforces system‑defined policies (SELinux, AppArmor) that restrict even root.

02 Unix Permission

Unix Permission classifies subjects as owner (u), group (g) or others (o) and objects as files or directories. Access is governed by three bits (rwx) whose meaning differs for files and directories.

Subject: user or process, classified as u, g, or o.

Object: file or directory.

Rules: three permission bits (rwx) with distinct file and directory semantics.

Special Permission Bits

SUID – executing the file temporarily gains the file owner’s privileges.

SGID – similar to SUID but affects the file’s group privileges.

Sticky Bit – on directories, users may delete only their own files (commonly used on /tmp).

JuiceFS Permission Verification

JuiceFS is a FUSE‑based user‑space filesystem. It enables default_permissions by default, so the kernel performs Unix Permission checks before forwarding requests to JuiceFS.

JuiceFS also performs its own permission checks for SDK calls (which bypass the kernel) and when the squash feature is enabled.

SDK Access : SDK requests do not pass through the kernel, therefore JuiceFS must enforce permissions internally.

Squash Feature : When enabled, JuiceFS maps certain users to a specified user, requiring user‑space permission checks.

Two squash modes are demonstrated.

root‑squash – maps the local root user to another UID/GID, preventing unrestricted root modifications.

# root in /tmp/jfs
$ ll /tmp/jfs/f1
-rw------- 1 user2 user2 0 Feb 19 16:26 /tmp/jfs/f1
# read as user2
$ cat /tmp/jfs/f1
hello

# mount with root‑squash=1001:1001
./juicefs mount sqlite3://test.db /tmp/jfs -o allow_other -root-squash=1001:1001
# attempt to read as user2 (now mapped to user1)
$ cat /tmp/jfs/f1
cat: /tmp/jfs/f1: Permission denied

all‑squash – maps all users to a single specified UID/GID, useful for unified permission management (available in JuiceFS 1.3).

# mount with all‑squash=1001:1001
./juicefs mount sqlite3://test.db /tmp/jfs -o allow_other -all-squash=1001:1001
# user2 creates a file
$ whoami
user2
$ touch f1
# user3 creates a file
$ whoami
user3
$ touch f2
$ ls -l .
-rw-rw-r-- 1 user1 user1 0 Feb 19 14:10 f1
-rw-rw-r-- 1 user1 user1 0 Feb 19 14:11 f2

03 POSIX ACL

POSIX ACL extends DAC by allowing arbitrary users or groups to be granted specific rwx rights. Implemented in Linux kernel 2.5.46 (2002) based on draft POSIX 1003.1e.

type Permission struct {
    Owner Mode
    Group Mode
    Other Mode
}

type ACL struct {
    Owner Mode
    Group Mode
    Other Mode
    Mask Mode // upper bound for group class
    NamedUsers Entry // specific user permissions
    NamedGroups Entry // specific group permissions
}

type Entry struct {
    Uid uint32
    Perm Mode
}

Two ACL categories:

Minimal ACL – equivalent to standard Unix Permission.

Extended ACL – includes any named user or group entries.

Setting an ACL modifies the group class (mask) dynamically.

# setfacl -m g:group1:rwx d1
# getfacl d1 --omit-header
user::rwx
group::r-x #effective:--x
group:group1:rwx #effective:-wx
mask::-wx
other::r-x

ACL Types

Access ACL – used for permission checks on files and directories.

Default ACL – same structure but applied only to directories; child objects inherit from the parent’s default ACL.

# setfacl -m u:user1:rwx d1
# setfacl -d -m u:user1:rwx d1
# getfacl -c d1
user::rwx
user:user1:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:user1:rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Access ACL Permission Evaluation

When a process requests access, the kernel (or JuiceFS) searches ACL entries in the following order:

owner

named users

owning or named groups

others

If multiple group entries match, the entry that grants the required permission is used; if none grant, the request is denied.

04 Capability – Fine‑Grained Privilege Subsets

Since Linux kernel 2.2, capabilities split root privileges into distinct abilities. JuiceFS 1.3 can enable capability support, which requires both --enable-xattr and --enable-cap mount options. Enabling capabilities adds metadata‑request overhead.

# ./juicefs mount sqlite3://test.db /tmp/jfs --enable-cap --enable-xattr
# sudo setcap 'cap_chown=+ep' bin
# getcap bin
bin cap_chown=ep

05 SELinux – Mandatory Access Control Module

SELinux enforces MAC policies via security contexts stored in extended attributes. To use SELinux with JuiceFS 1.3, mount with --enable-selinux and --enable-xattr. Both flags are disabled by default.

06 Summary

JuiceFS integrates Linux DAC mechanisms (Unix Permission, POSIX ACL) and MAC mechanisms (SELinux). It relies on kernel‑level checks via default_permissions, adds user‑space checks for SDK access and squash modes, stores ACLs as global IDs to reduce metadata duplication, and optionally supports capabilities and SELinux when the corresponding mount options are enabled.