# Keep declared service state writable under ProtectSystem=strict

> Identify the service’s real write locations before weakening a systemd filesystem restriction.

- Canonical URL: https://update.dsesecurity.com/updates/systemd-protectsystem-strict-state-directories/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T00:43:31+00:00
- Modified: 2026-10-15T00:44:33+00:00
- Last reviewed by DSE: 2026-10-14
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Identify the service’s real write locations before weakening a systemd filesystem restriction.

## Potentially affected

Use this guide for Linux system services with compatible systemd behavior. Check the installed systemd manual and execution environment, especially inside containers or user-service configurations.

## DSE recommendation

DSE recommends inventorying durable state, cache, logs, runtime files, and configuration separately.

## Article

Identify the service’s real write locations before weakening a systemd filesystem restriction.

## Source facts

The systemd version 257 manual describes ProtectSystem=strict as making the filesystem hierarchy read-only for a service, except for specified API filesystem subtrees. StateDirectory, LogsDirectory, and related directory settings exclude their managed locations from that restriction. ReadWritePaths can also define exceptions. The manual notes that filesystem namespace support is required and that these settings have limitations; a unit-file directive alone is not proof of effective confinement.

Source: [systemd project — systemd.exec manual source, version 257](https://raw.githubusercontent.com/systemd/systemd/v257/man/systemd.exec.xml).

## Applicability

Use this guide for Linux system services with compatible systemd behavior. Check the installed systemd manual and execution environment, especially inside containers or user-service configurations.

## DSE recommendation

DSE recommends inventorying durable state, cache, logs, runtime files, and configuration separately. Prefer the appropriate managed directory setting for a service’s declared data, with ownership and application paths reviewed together. Keep any remaining writable exception limited to a documented requirement. Avoid opening an entire filesystem tree because one write failed. Preserve the previous unit configuration and arrange a maintenance window that includes the application’s normal restart and recovery operations.

## Verification

In a representative test environment, verify that legitimate state and log writes succeed and an unrelated write is denied. Restart the service and check retained state. Record the effective unit, runtime environment, expected paths, and observed failures before accepting the restriction.

## Official reference

[systemd project — systemd.exec manual source, version 257](https://raw.githubusercontent.com/systemd/systemd/v257/man/systemd.exec.xml). Reviewed October 14, 2026.

## Primary reference

- Name: systemd project — systemd.exec manual source, version 257
- Authority: raw.githubusercontent.com
- URL: https://raw.githubusercontent.com/systemd/systemd/v257/man/systemd.exec.xml
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Keep declared service state writable under ProtectSystem=strict,” DSE Security, https://update.dsesecurity.com/updates/systemd-protectsystem-strict-state-directories/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.