Connect My Computer: Do not omit checking all permissions when the agent is configured

[gzdunek]

Contributes to #27881

When I added showing CMC when the user has permissions or the agent has been configured, I took too simple approach.
Some permissions should be always checked, like a feature flag or OS, otherwise it can lead to bugs:

• When a user configures the agent in version 14.1.0 and then downgrades to version 14.0.0, they will see a feature that is not fully completed.
• When the user creates a configuration file on Windows, they will see the feature that will not work.

[ravicious]

• When a user configures the agent in version 14.1.0 and then downgrades to version 14.0.0, they will see a feature that is not fully completed.

This is a valid concern.

• When the user creates a configuration file on Windows, they will see the feature that will not work.

I wouldn't worry about this, the internals of ~/Library/Application Support/Teleport Connect should be considered private.

---

We don't have a "formalized" permission system in Connect and IMHO the requirements in this PR serve as a good example as to why arbitrary functions are bad for this.

If anything, the requirement behind the feature flag always gating access to the feature (no matter if you have permissions or if the agent was configured) suggests to me that the feature flag check should be done outside of permissions. So we should really think of it in three categories:

isFeatureFlagEnabled && (hasPermissions || hasConfiguredAgent)

This also illustrates better the intent behind the checks. What we described in the RFD is that we want the user to always have access to the agent after the user sets up the agent. So even if the admin changes permissions so that technically the user is not able to set up a new agent, we still want the user to have the ability to manage the agent that was already set up.

But here instead of making the distinction between permissions, feature flag and feature state more clear, we add them app together.

I think about it like this: if we wanted to make a more formalized API for permissions, we'd likely want to consider the permissions based on the user state and the runtime settings, so that the API can be uniform for all different kinds of permissions. If each one require some additional data specific for a single use case, the API would get a bit unwieldy.

---

I think your previous solution was good. If we skip the second point about creating a config file on Windows and are left just with the one about the feature flag, as I said before, in my eye it's an argument to the feature flag check out of canUseConnectMyComputer.

[gzdunek]

I think you are right, putting another parameters into canUseConnectMyComputer makes its API quite bad.
Thanks for writing down the condition (isFeatureFlagEnabled && (hasPermissions || hasConfiguredAgent)), it opened my eyes on what exactly we want to check.

Pushed a commit that refactors it.

[ravicious]

We could note here what we said in the RFD, that the user should always have access to the agent after configuring it and link to relevant section of the RFD.

[public-teleport-github-review-bot]

@gzdunek See the table below for backport results.

Branch	Result
branch/v14	Create PR