Enable unprivileged on macos#4362
Conversation
3a4bd8c to
29e64a8
Compare
|
This pull request does not have a backport label. Could you fix it @pchila? 🙏
NOTE: |
980f9f8 to
e5d7ea9
Compare
|
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
| // Deprecated: MacOS can be run/installed without root privileges | ||
| cmd.Flags().Bool("disable-encrypted-store", false, "Disable the encrypted disk storage (Only useful on Mac OS)") | ||
| _ = cmd.Flags().MarkHidden("disable-encrypted-store") | ||
| _ = cmd.Flags().MarkDeprecated("disable-encrypted-store", "agent on Mac OS can be run/installed without root privileges, see elastic-agent install --help") |
internal/pkg/agent/cmd/run.go
Outdated
| // try early to check if running as root | ||
| isRoot, err := utils.HasRoot() | ||
| if err != nil { | ||
| return fmt.Errorf("failed to check for root permissions: %w", err) |
There was a problem hiding this comment.
The others you added used the word administrator and this one used root. I believe that was just because this was moved. I would like to see this consitent, maybe root/Administrator would be better and work for unix and windows.
|
|
||
| hasRoot, err := utils.HasRoot() | ||
| if err != nil || !hasRoot { | ||
| // TODO log error |
There was a problem hiding this comment.
|
We don't have a MacOS runner for integration tests yet. What is the plan for ensuring this works with the same level of confidence as Windows and Linux? We have a manual QA team that can help verify this, but we'd have to provide a detailed list of test cases first. |
Not sure what other testcases may come to mind but here's what I have tested:
Aside from checking manually that privileged still works I cannot think of specific additional scenarios to test. We have a real problem with automated testing for this kind of changes, unit tests are unfeasible without massive refactoring in the touched parts of code (I would like to avoid a big-bang scenario) and we don't have runners for integration tests on Mac as you pointed out. |
87b84e7 to
b508570
Compare
blakerouse
left a comment
There was a problem hiding this comment.
Looks great!
Thanks for adding tests where you could, a lot of these areas are really hard to unit tests.
Do upgrades work?
Long term the answer is to add a MacOS integration test runner, I don't expect this to be covered purely with unit tests. |
Checking if we are running as root when creating the EncryptedDiskStore removes the need for propagating an unprivileged flag from a lot of places in the code. Only exception is the uninstall command, since it needs to run with administrator privileges: in there we check for existence of a FileVault containing the agent secret to detect if we have to load the agent configuration as unprivileged (currently relevant only on Darwin)
b508570 to
795bbbe
Compare
|
@cmacknz I just tested by repackaging the agent (we cannot downgrade as the old agent versions do not support running unprivileged) and everything works as expected when launching the upgrade with |
cc @rowlandgeoff to ensure this is under your radar. |
|
As discussed in our weekly meeting, this PR contains what is possible to be tested until we have our MacOS runner so I'm force merging even if SonarQube is not happy with the coverage level. |

33.3% Coverage on New Code
What does this PR do?
This PR allows running elastic-agent (either installed or just extracted from the package) as an unprivileged user, using a file-based vault as fallback instead of the keychain-based one.
When creating an EncryptedDiskStore, we can specify an
unprivilegedflag which will instantiate the file-based vault on Mac OS (the default value of such flag is defined as whether elastic-agent is running with administrative rights).In most cases, such default value is enough to choose the correct vault implementation: the exception is
elastic-agent uninstallcommand where a specific check for a file vault containing the agent secret has been added.The additional check during uninstall is necessary since the command needs to run with administrative rights for both privileged and unprivileged elastic-agent installs (a simple check of the user permissions would not be useful as we would always come up with privileged permissions)
Why is it important?
This change enables
elastic-agentto be installed and run as an unprivileged user on Mac OSChecklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files./changelog/fragmentsusing the changelog tool[ ] I have added an integration test or an E2E testAuthor's Checklist
How to test this PR locally
Related issues
--unprivilegedon macOS #3867Use cases
Screenshots
Logs
Questions to ask yourself