Add note about application posture check path comparison #16923
Conversation
Deploying cloudflare-docs with
|
| Latest commit: |
d63d727
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://d1056a61.cloudflare-docs-7ou.pages.dev |
| Branch Preview URL: | https://update-application-posture-c.cloudflare-docs-7ou.pages.dev |
| @@ -37,6 +37,7 @@ The Application Check device posture attribute checks that a specific applicatio | |||
|
|
|||
| - Be sure to enter the binary file path, not the application launch path. When checking for an application on macOS, a common mistake is to enter `/Applications/ApplicationName.app`. This will not work as `ApplicationName.app` is a folder. The executable file that will be running is located within the folder, for example `ApplicationName.app/Contents/MacOS/ApplicationName`. | |||
| - Some applications change their file path after an update. Ensure that the application is always in a stable location, or use an environment variable to identify a specific folder. For example, Windows provides [recognized environment variables](https://learn.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables) that you can reference in your file path (`%PROGRAMFILES%\myfolder\myfile.exe`). | |||
| - The path entered in the dashboard is canonicalized. The full path of the process (once confirmed to be running) is also canonicalized. The two must match for the application check to be true. | |||
There was a problem hiding this comment.
I'm not sure what canonicalized means in this context. Could we add an example?
There was a problem hiding this comment.
It is essentially expanding the paths to its complete, absolute form so they can be accurately compared.
How about this?
The path you enter in the dashboard is adjusted to its complete, absolute form. The path of the process (once confirmed to be running) is also converted to this absolute form. Both paths need to match exactly for the application check to pass.
I am fine with leaving this out of the documentation as it is more of an implementation detail. Do you think it's useful to have for customers?
There was a problem hiding this comment.
I think a concrete example would help to understand the behavior (e.g. We canonicalize the path specified in the dash, so /etc/omonitor/<app name> transforms to /private/etc/omonitor/<app name>) What are the steps to test whether the dash path and process path match?
There was a problem hiding this comment.
Okay, how does this sound?
The path entered in the dashboard is canonicalized. The full path of the process (once confirmed to be running) is also canonicalized. The two must match for the application check to be true. For example, if `/bin/<binary>` is entered in the dashboard but `/bin` is a symlink to `/usr/bin`, the path will be canonicalized to `/usr/bin/<binary>`. It doesn't matter whether `/bin/<binary>` or `/usr/bin/<binary>` is specified—both will resolve to `/usr/bin/<binary>` for the check to succeed.
Thinking about this again, I am not sure if we want to add the note (above) at all. It may turn out to be more confusing than helpful.
Perhaps a more helpful change would be to the testing steps. Users can currently make use of the commands listed here. These are all accurate except macOS, which should be updated to ps -eo comm | xargs which | sort | uniq | xargs realpath (include xargs realpath).
Context
SHELP-384 exposed an issue with the WARP client, where Application type posture checks may not be working as expected under certain conditions. In brief, the issue was due to how the client compares the user-specified path in the dashboard against the path of the running process. The issue was been fixed by CLIENT-10539.
Summary
This PR adds some additional details to the note on the application check page.
This PR should NOT be merged before the new version with the fix is released (planned for the week of Nov 4th)
Documentation checklist