# Check the Linux agent script identity separately from its Checkmk controller user > Distinguish a non-root Agent Controller from non-root execution of the agent script, preserving the package and directory prerequisites. - Canonical URL: https://update.dsesecurity.com/updates/check-the-linux-agent-script-identity-separately-from-its-checkmk-controller-user/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:47:01+00:00 - Modified: 2026-10-30T06:47:29+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Distinguish a non-root Agent Controller from non-root execution of the agent script, preserving the package and directory prerequisites. ## Potentially affected Commercial-edition Checkmk Linux agents installed as DEB or RPM packages using the documented single-directory setup. ## DSE recommendation Verify the script and controller identities separately, then review privileged observations individually. ## Article Bottom line: For commercial Linux DEB/RPM agent packages, distinguish a non-root Agent Controller from genuinely non-root script execution; preserve the single-directory prerequisite and review missing privileged observations separately. ## Source fact: what the authority says The [Checkmk unprivileged-agent guide](https://docs.checkmk.com/latest/en/agent_single_folder.html) initially scopes the fully usable feature to commercial-edition Linux DEB or RPM agents installed within one directory. Its default root-agent configuration runs the controller as cmk-agent but still executes the agent script as root. The non-root agent option runs both the controller and script under the specified user. The guide warns that non-root execution provides fewer functions and requires distribution- and organization-specific methods for missing privileged observations. ## What the source does not establish This article reviews the documented commercial Linux package path, not the separate legacy transports or Solaris/AIX execution model. It does not promise identical check coverage, authorize broad sudo access or certify an arbitrary plug-in as safe. ## Applicability questions - Does the installed commercial Linux package meet the documented package and directory conditions? - Which identities execute the Agent Controller and the agent script? - Which required observations need permissions unavailable to the proposed script user? - Who approves each narrow privilege exception and its maintenance? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends recording controller and script identities in separate fields before changing the agent package. Compare the intended package rule with the actual installed layout. Avoid calling the entire agent unprivileged merely because one process belongs to a non-root account; require the actual script execution context in the review. Define the monitoring observations that the deployment must retain. Have the host owner identify the files, devices or commands needed for each, using the installed distribution’s supported procedure. Keep a missing observation as an explicit gap instead of silently accepting reduced coverage after a privilege change. Review narrowly scoped permissions or execution exceptions with the security owner. Prefer a documented rationale for each required observation over copying an entire privilege template without assessment. Keep plug-in ownership, executable integrity and maintenance responsibilities with that exception; do not grant broad administration merely to restore a green overview. Use a representative test host and an approved package build before wider deployment. Preserve the prior identity and permission configuration, and define the condition for returning to it. Keep legacy transport changes and unrelated agent upgrades outside this trial so the source of any missing data remains identifiable. ## Verification and evidence Proposed verification: inspect both effective execution identities and the installed package layout, then compare the named observations with the prior approved baseline. Retain the exact check population, actual data and permission diagnostics rather than reporting a universal coverage result. Where a narrow exception is approved, repeat only its associated observation and check the resulting privilege scope separately. Have the host and monitoring owners accept remaining gaps before rollout. Record package identity, distribution, configuration and unresolved findings, without claiming every plug-in supports non-root execution. ## Official references - [Checkmk — Unprivileged execution of the Linux agent](https://docs.checkmk.com/latest/en/agent_single_folder.html) — official product documentation; confirm the installed release and configuration. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Checkmk — Unprivileged execution of the Linux agent - Authority: docs.checkmk.com - URL: https://docs.checkmk.com/latest/en/agent_single_folder.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check the Linux agent script identity separately from its Checkmk controller user,” DSE Security, https://update.dsesecurity.com/updates/check-the-linux-agent-script-identity-separately-from-its-checkmk-controller-user/ 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.