Fix/deduplication privilege level change

[michalpristas]

This PR adds some kind of deduplication layer for privilege level change, in case we're already running unelevated it checks desired user and group and if they match current user action is considered duplicate and acked successfully only with warning in logs.

In case of mismatch it fails with error

Fixes: #11993

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[ycombinator]

In addition to the unit test added for the new function, targetingSameUser, would it be possible to write a unit test covering the new logic in the handle method? The test could be skipped if utils.HasRoot() returns true so that you only need to test the various cases in the if !isRoot block, i.e. the new logic added in this PR. Essentially, we'd want to check if ackCommitFn, featuring a mocked acker, is called if we're targeting the same user, indicating that deduplication is happening OR if we're not targeting the same user, the expected error is thrown.

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: d83cb5d

Failed CI Steps

• arm:sudo: default

History

• 💔 Build #32860 failed 614e31d
• 💔 Build #32854 failed 42b97ee

cc @michalpristas

[cmacknz]

An integration test that sends the privilege level change action twice in a row would probably be the best thing to test this, considering how coupled it is to how agent is installed I am skeptical we can cover the action implementation purely with unit tests.

There are integration tests for the command line version of this already but I don't see one for the action.

elastic-agent/testing/integration/ess/switch_unprivileged_test.go

Line 28 in adab9b6

func TestSwitchUnprivilegedWithoutBasePath(t *testing.T) {