Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Effective project handling in the events API #13962

Open
markylaing opened this issue Aug 22, 2024 · 0 comments
Open

Effective project handling in the events API #13962

markylaing opened this issue Aug 22, 2024 · 0 comments
Assignees
Labels
Improvement Improve to current situation

Comments

@markylaing
Copy link
Contributor

Consider the following:

# Via unix or as administrator
$ lxc project create foo # `features.networks` & `features.networks.zones` disabled on creation be default.
$ lxc config trust add <cert> --restricted --projects foo

# Restricted cert
$ lxc monitor --all-projects --type lifecycle
$ lxc network create foo-network --project foo

The restricted certificate will not see the lifecycle event relating to the creation of their network, because the network was created in the default project.

We should discuss whether it is possible to address this. Some initial ideas would be:

  1. Duplicate events in the default project and emit one for each project where that feature is disabled.
  2. Add some "source project" property to events.
  3. Don't handle it for existing TLS users, expect that an administrator will add can_view_events for the default project where a group is confined to a project with any features disabled.
  4. Don't handle it for existing TLS users, add logic to include a source entity in the event, fine-grained users can view the event if they have can_view on the entity.

Note that 4. would be generally useful. We currently require that the can_exec entitlement on an instance be paired with can_view_events on the parent project because the client uses the events websocket instead of operations (to avoid creation of multiple connections). We've discussed how to fix this before in #12885, as using operations can be problematic (connections dropping when performing a long pool).

See #13886 (comment)_

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Improvement Improve to current situation
Projects
None yet
Development

No branches or pull requests

2 participants