Fix /boot permissions security vulnerability by kuro-toji · Pull Request #5418 · basecamp/omarchy

kuro-toji · 2026-04-24T06:04:13Z

Summary

Fixes a security vulnerability where the /boot mount point and random-seed file were world accessible.

Issue

bootctl was logging warnings:

Fix

Sets /boot directory permissions to 700 (owner only)
Sets random-seed file permissions to 600 (owner read/write)
Runs bootctl random-seed to regenerate with correct permissions

Files Changed

install/config/boot-permissions-fix.sh - New installer script
migrations/1777007500.sh - Migration to fix existing installations

Testing

Check current /boot permissions: stat -c %a /boot
Should return 700
Check random-seed: stat -c %a /boot/loader/random-seed
Should return 600

Fixes: #5377

Copilot

Pull request overview

This PR aims to remediate a reported security issue where /boot (the mount backing the boot random seed) and /boot/loader/random-seed are world-accessible, triggering bootctl warnings.

Changes:

Adds an installer-time script to adjust /boot and random-seed permissions and trigger bootctl random-seed.
Adds a migration to fix permissions on existing installations and notify the user.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

File	Description
`install/config/boot-permissions-fix.sh`	New install config script intended to harden `/boot` and `random-seed` permissions and run `bootctl random-seed`.
`migrations/1777007500.sh`	New migration to update permissions on existing systems and notify the user.

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-24T06:08:26Z

+# Fix /boot directory permissions (should be 700)
+sudo chmod 700 /boot 2>/dev/null || echo "Could not change /boot permissions"
+
+# Fix random-seed file permissions if it exists
+if [[ -f /boot/loader/random-seed ]]; then
+  sudo chmod 600 /boot/loader/random-seed 2>/dev/null || echo "Could not change random-seed permissions"
+fi
+
+# Ensure /boot is mounted with proper permissions
+# Add to fstab if not already present with correct options
+if ! grep -q "^/boot" /etc/fstab 2>/dev/null; then
+  echo "Warning: /boot is not in fstab, permissions may not persist"


chmod may not actually change effective permissions on a typical EFI System Partition (vfat/fat), because the mode bits are derived from mount options (umask/fmask/dmask). In that case this script won’t resolve bootctl’s “world accessible mount point” warning; consider detecting the filesystem type for /boot and enforcing restrictive mount options (e.g., umask/dmask/fmask) instead of (or in addition to) chmod.

Suggested change

# Fix /boot directory permissions (should be 700)

sudo chmod 700 /boot 2>/dev/null || echo "Could not change /boot permissions"

# Fix random-seed file permissions if it exists

if [[ -f /boot/loader/random-seed ]]; then

sudo chmod 600 /boot/loader/random-seed 2>/dev/null || echo "Could not change random-seed permissions"

fi

# Ensure /boot is mounted with proper permissions

# Add to fstab if not already present with correct options

if ! grep -q "^/boot" /etc/fstab 2>/dev/null; then

echo "Warning: /boot is not in fstab, permissions may not persist"

boot_fs_type=""

boot_mount_options=""

if command -v findmnt &>/dev/null && findmnt -n --target /boot &>/dev/null; then

boot_fs_type="$(findmnt -n -o FSTYPE --target /boot 2>/dev/null)"

boot_mount_options="$(findmnt -n -o OPTIONS --target /boot 2>/dev/null)"

fi

if [[ "$boot_fs_type" =~ ^(vfat|fat|msdos)$ ]]; then

echo "/boot is mounted on $boot_fs_type; applying mount masks because chmod may not change effective permissions"

if [[ "$boot_mount_options" == *"umask=0077"* ]] || [[ "$boot_mount_options" == *"dmask=0077"* && "$boot_mount_options" == *"fmask=0177"* ]]; then

echo "/boot already has restrictive mount options"

else

sudo mount -o remount,dmask=0077,fmask=0177 /boot 2>/dev/null || echo "Could not remount /boot with restrictive permissions"

fi

# chmod is not reliable on FAT-family filesystems; effective permissions come from mount options

if grep -Eq '^[^#[:space:]]+[[:space:]]+/boot[[:space:]]+' /etc/fstab 2>/dev/null; then

if ! grep -Eq '^[^#[:space:]]+[[:space:]]+/boot[[:space:]]+[^[:space:]]+[[:space:]]+[^#[:space:]]*(umask=0077|dmask=0077[^#[:space:]]*fmask=0177|fmask=0177[^#[:space:]]*dmask=0077)' /etc/fstab 2>/dev/null; then

echo "Warning: /boot is in fstab without restrictive mount options; add dmask=0077,fmask=0177 (or umask=0077) for persistence"

fi

else

echo "Warning: /boot is not in fstab, restrictive mount options may not persist"

fi

else

# Fix /boot directory permissions (should be 700)

sudo chmod 700 /boot 2>/dev/null || echo "Could not change /boot permissions"

# Fix random-seed file permissions if it exists

if [[ -f /boot/loader/random-seed ]]; then

sudo chmod 600 /boot/loader/random-seed 2>/dev/null || echo "Could not change random-seed permissions"

fi

# Ensure /boot is mounted with proper permissions

# Add to fstab if not already present with correct options

if ! grep -Eq '^[^#[:space:]]+[[:space:]]+/boot[[:space:]]+' /etc/fstab 2>/dev/null; then

echo "Warning: /boot is not in fstab, permissions may not persist"

fi

Copilot · 2026-04-24T06:08:27Z

+#!/bin/bash
+
+# Fix /boot permissions security issue
+# The random seed file and /boot mount should not be world accessible
+# See: https://github.com/basecamp/omarchy/issues/5377
+
+echo "Fixing /boot permissions for better security..."


This new installer script doesn’t appear to be invoked by the install flow (no references under install/config/all.sh or elsewhere), so the fix won’t apply on fresh installs. Consider wiring it into the appropriate install/config/*/all.sh sequence so it actually runs.

Copilot · 2026-04-24T06:08:27Z

+  echo "✓ random-seed permissions fixed to 600"
+fi
+
+notify-send "Boot permissions fixed" "Security improvement applied to /boot"


notify-send is the last command in the migration, and it can exit non-zero in non-graphical contexts (no DBus session), causing the migration to be marked as failed and prompting the user. Guard it (check command -v notify-send and a session bus) or make it non-fatal (e.g., ignore failures).

Suggested change

notify-send "Boot permissions fixed" "Security improvement applied to /boot"

if command -v notify-send >/dev/null 2>&1 && [[ -n "${DBUS_SESSION_BUS_ADDRESS:-}" ]]; then

notify-send "Boot permissions fixed" "Security improvement applied to /boot" || true

fi

Copilot · 2026-04-24T06:08:28Z

+# Fix /boot directory permissions (should be 700 for security)
+sudo chmod 700 /boot 2>/dev/null || echo "Could not change /boot permissions"
+
+# Fix random-seed file permissions if it exists
+if [[ -f /boot/loader/random-seed ]]; then
+  sudo chmod 600 /boot/loader/random-seed 2>/dev/null || echo "Could not change random-seed permissions"
+fi


This migration attempts to fix the bootctl warnings but only uses chmod. If /boot is an EFI/FAT filesystem, chmod won’t change effective permissions and the warnings will persist; the migration should instead adjust /boot mount options (umask/fmask/dmask) or at least detect that case and report/fail clearly so the user can remediate.

Copilot · 2026-04-24T06:08:28Z

+# Fix random-seed file permissions if it exists
+if [[ -f /boot/loader/random-seed ]]; then
+  sudo chmod 600 /boot/loader/random-seed 2>/dev/null || echo "Could not change random-seed permissions"
+fi


The PR description says we “run bootctl random-seed to regenerate with correct permissions”, but the migration doesn’t do that. Without re-running random-seed generation, systems with an existing world-accessible seed may not be fully remediated (and systems missing the file won’t get it). Consider running bootctl random-seed (non-fatal if bootctl isn’t present) as part of the migration.

Copilot · 2026-04-24T06:08:28Z

+# Disable bootctl random seed generation warnings by setting correct permissions
+if command -v bootctl &>/dev/null; then
+  # Run bootctl with proper environment to set correct permissions
+  sudo bootctl random-seed 2>/dev/null || true
+fi
+
+echo "Boot permissions fix complete!"


The script always prints “Boot permissions fix complete!” even if chmod fails (errors are suppressed) and even if the resulting permissions remain unchanged. Consider explicitly checking the resulting mode (and/or filesystem type) and reporting failure so users don’t get a false sense of remediation.

The /boot mount point and random-seed file were world accessible, which is a security issue per bootctl warnings. This fix: - Sets /boot directory permissions to 700 - Sets random-seed file permissions to 600 - Runs bootctl random-seed to regenerate with correct permissions Fixes: basecamp#5377

Copilot AI review requested due to automatic review settings April 24, 2026 06:04

Copilot started reviewing on behalf of kuro-toji April 24, 2026 06:04 View session

Copilot AI reviewed Apr 24, 2026

View reviewed changes

kuro-toji force-pushed the fix/boot-permissions-security branch from e5d1c51 to 0afa15a Compare April 24, 2026 06:17

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix /boot permissions security vulnerability#5418

Fix /boot permissions security vulnerability#5418
kuro-toji wants to merge 1 commit intobasecamp:devfrom
kuro-toji:fix/boot-permissions-security

kuro-toji commented Apr 24, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 24, 2026

Uh oh!

Copilot AI Apr 24, 2026

Uh oh!

Copilot AI Apr 24, 2026

Uh oh!

Copilot AI Apr 24, 2026

Uh oh!

Copilot AI Apr 24, 2026

Uh oh!

Copilot AI Apr 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

-notify-send "Boot permissions fixed" "Security improvement applied to /boot"
+if command -v notify-send >/dev/null 2>&1 && [[ -n "${DBUS_SESSION_BUS_ADDRESS:-}" ]]; then
+  notify-send "Boot permissions fixed" "Security improvement applied to /boot" || true
+fi

Conversation

kuro-toji commented Apr 24, 2026

Summary

Issue

Fix

Files Changed

Testing

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants