Skip to content

docs: document symlink permission behavior#2958

Merged
bartlomieju merged 4 commits intodenoland:mainfrom
kajukitli:docs-symlink-permissions
Mar 9, 2026
Merged

docs: document symlink permission behavior#2958
bartlomieju merged 4 commits intodenoland:mainfrom
kajukitli:docs-symlink-permissions

Conversation

@kajukitli
Copy link
Contributor

Adds documentation for how Deno handles permissions for symbolic links, addressing https://github.com/denoland/deno/security/advisories/GHSA-jxwh-q9gp-f7j9.

Changes

Adds a new "Symbolic links" subsection under "File system access" that explains:

  • Permissions are checked based on the symlink's location, not its target
  • Privilege escalation is prevented for sensitive paths (/proc, /dev, /sys)
  • Special handling for /proc/**/environ (requires --allow-env)
  • Safe device files (/dev/null, /dev/zero, etc.) are always accessible
  • Creating symlinks requires full --allow-read and --allow-write
  • Pre-existing symlinks are not subject to creation restrictions

This clarifies the security model around symlinks so users understand the expected behavior.

Adds a new section under File System Access explaining how Deno handles
permissions for symbolic links:

- Permissions are checked on symlink location, not target
- Escalation prevention for sensitive paths (/proc, /dev, /sys)
- Safe device files that are always accessible
- Symlink creation requires full read+write permissions
- Pre-existing symlinks are not subject to creation restrictions
Comment on lines +236 to +237
> what your code can create and access, not what already exists on the
> filesystem.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a confusing phrasing - "The permission model only governs what your code can create and access," - except that "access" is goverened by the symlink location not the target location, which then , which then feels weird if you say "not what already exists on the FS" (because it's exactly about what is already on the FS).

kajukitli and others added 3 commits March 6, 2026 09:20
Address review feedback - the previous phrasing was confusing about
what 'access' means vs 'create'.
@bartlomieju bartlomieju merged commit 5e1a7dc into denoland:main Mar 9, 2026
1 check passed
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.

3 participants