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.
\nThe Checkmk unprivileged-agent guide 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.
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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nDefine 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.
\nReview 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.
\nUse 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.
\nProposed 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.
\nWhere 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe Checkmk unprivileged-agent guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nDoes the installed commercial Linux package meet the documented package and directory conditions?\nWhich identities execute the Agent Controller and the agent script?\nWhich required observations need permissions unavailable to the proposed script user?\nWho approves each narrow privilege exception and its maintenance?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nDefine 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.\nReview 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.\nUse 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.\nVerification and evidence\nProposed 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.\nWhere 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.\nOfficial references\n\nCheckmk — Unprivileged execution of the Linux agent — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Does the installed commercial Linux package meet the documented package and directory conditions?\n\n- Which identities execute the Agent Controller and the agent script?\n\n- Which required observations need permissions unavailable to the proposed script user?\n\n- Who approves each narrow privilege exception and its maintenance?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nDefine 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.\n\nReview 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.\n\nUse 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.\n\n## Verification and evidence\n\nProposed 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.\n\nWhere 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.\n\n## Official references\n\n- [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.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/check-the-linux-agent-script-identity-separately-from-its-checkmk-controller-user/", "url": "https://update.dsesecurity.com/updates/check-the-linux-agent-script-identity-separately-from-its-checkmk-controller-user/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-the-linux-agent-script-identity-separately-from-its-checkmk-controller-user/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Check the Linux agent script identity separately from its Checkmk controller user", "item": "https://update.dsesecurity.com/updates/check-the-linux-agent-script-identity-separately-from-its-checkmk-controller-user/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-the-linux-agent-script-identity-separately-from-its-checkmk-controller-user/#article", "identifier": "https://update.dsesecurity.com/updates/check-the-linux-agent-script-identity-separately-from-its-checkmk-controller-user/", "url": "https://update.dsesecurity.com/updates/check-the-linux-agent-script-identity-separately-from-its-checkmk-controller-user/", "headline": "Check the Linux agent script identity separately from its Checkmk controller user", "description": "Distinguish a non-root Agent Controller from non-root execution of the agent script, preserving the package and directory prerequisites.", "abstract": "Distinguish a non-root Agent Controller from non-root execution of the agent script, preserving the package and directory prerequisites.", "articleBody": "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.\nSource fact: what the authority says\nThe Checkmk unprivileged-agent guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nDoes the installed commercial Linux package meet the documented package and directory conditions?\nWhich identities execute the Agent Controller and the agent script?\nWhich required observations need permissions unavailable to the proposed script user?\nWho approves each narrow privilege exception and its maintenance?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nDefine 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.\nReview 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.\nUse 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.\nVerification and evidence\nProposed 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.\nWhere 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.\nOfficial references\n\nCheckmk — Unprivileged execution of the Linux agent — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:47:01+00:00", "dateModified": "2026-10-30T06:47:29+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-the-linux-agent-script-identity-separately-from-its-checkmk-controller-user/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/check-the-linux-agent-script-identity-separately-from-its-checkmk-controller-user/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check the Linux agent script identity separately from its Checkmk controller user" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 521, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Checkmk — Unprivileged execution of the Linux agent", "url": "https://docs.checkmk.com/latest/en/agent_single_folder.html" } } ] } }