Endpoint Automation triggers
This article explains how the 1E Client monitors specified files for changes and triggers associated policies when modifications occur. To prevent event overload from frequently changing files, it enforces a minimum two-second interval between generated events. For more details about triggers, refer to our SDK documentation Guaranteed State Triggers.
File change detection
File change detection is a trigger associated with a rule. Triggers when a nominated file is modified, including created or deleted.
Linux
The LinuxFileChangeTrigger class watches directories to detect changes in files. When a file is created, edited, deleted, or renamed, it generates an event. The class checks if the file is important for a policy. If not, it ignores the event but logs it for debugging.
A file refers to any named object within a Linux filesystem directory. It can include any of the following:
-
A regular file
-
A subdirectory
-
A symbolic link (the link itself, not the filesystem object being pointed to)
-
A socket
-
A pipe
-
A block device
-
A character device
Actions that can be detected on a file:
-
Creation
-
Deletion
-
Renaming (but see below)
-
Change of contents (when the file is closed)
-
Change of properties (e.g. permissions)
Read-access to a file isn't detected because it doesn't alter the file in any way, even though it could be monitored.
-
In policy terms, a file is tracked by its path. If the file is renamed and moved, a trigger occurs, but the 1E Client loses track of it. If an unmonitored file is renamed to a monitored path, a trigger happens when it arrives. A file can be linked to multiple policies, and each gets notified of changes.
-
To avoid an excessive number of events from a frequently changing file, the 1E Client only generates an event if at least two seconds have passed since the previous one. This interval is fixed and cannot be changed.
-
If the parent directory of a file doesn't exist when the 1E Client starts, the file can't be monitored immediately. Once the directory is created, the 1E Client will begin monitoring the file within about a minute.
-
Pseudo-filesystems like /proc, /sys, and /dev/pts cannot be monitored, meaning file changes in these locations go undetected. The API does not report an error when attempting to monitor /proc (e.g., to track /proc/1), no events are generated when objects within /proc change.