Vates group | XCP-ng and XO forum

olivierlambert

Nice! Have you tested the snapshot, revert and so on?

dinhngtu

@ovicz Thanks for testing. Is everything working without the pci=nomsi or GRUB command line tweaks? We'll work to integrate this fix into a future update.

dinhngtu

@ovicz Are you up for a test package with a fix? Note that the fix is not yet tested nor supported at the moment.

Add user repos using this command:

yum-config-manager --add-repo https://koji.xcp-ng.org/repos/user/8/8.3/xcpng-users.repo

To know what you need to upgrade, run this command (as xcp-ng-ndinh2 contains some changes that you don't need):

rpm -qa --qf '%{NAME}\t%{SOURCERPM}\n' | grep $'\txapi'

Then upgrade just the XAPI-related packages:

yum update --enablerepo=xcp-ng-ndinh2 <list of packages from above>

Remember to reboot the host after installing.

Finally, disable hvm-pirq on your affected VM and reboot it (parameter name subject to change):

xe vm-param-set uuid=... platform:hvm-pirq=false

To go back, list what you installed and downgrade them:

yum list installed | grep ndinh
yum downgrade ...

poddingue

I'm late to this, but I've been building lately a JetBrains plugin against the REST API and ACL v2 turned out to decide its whole design, so here's some feedback.
Everything below is just one appliance, one pool (my small homelab), on a plan 4 trial, with an admin control call taken in the same breath as every scoped one.

What I experienced is that selectors narrow reads (tags: and id: both, 1 VM against an admin control of 11), they're re-evaluated per request rather than fixed when the privilege is created, deny composes the way your Carol example says (allow-all plus deny on a tag gave 9, which is 11 minus the 2 tagged), and they scope the power verbs too, not just reads.

The event stream is, to me, scoped as well, which was the thing I most wanted to check, because a scoped read next to an unscoped feed would have been a nasty trap. It's not.
With two streams open at once, a change to an out-of-scope VM produced an update on the admin stream and nothing at all on the scoped one, so it's genuinely filtered rather than merely quiet.
And the bit I'd underline: the same single change is update to the admin and add or remove to the scoped user. The verb is computed per subscriber, not per object. Across that run the admin only ever saw update, and I originally wrote that an admin never sees add or remove at all. That was wrong and I've since measured it: an admin does get add and remove when an object is genuinely created or deleted. So the rule is that a scope change reads as update and an existence change as add or remove, which supports your design better than what I first wrote did.
"From the user's perspective, not XOA's" turns out to be literal rather than a figure of speech, and that's a nicer piece of design than the sentence let me imagine.

Now the three things that I didn't see in the post above.

vm-snapshot is a separate privilege resource and vm doesn't imply it. Maybe that's obvious, but it was not obvious to me.
With all six VM privileges granted, GET /vm-snapshots came back empty while admin saw 6, including a snapshot the scoped user had just taken. Anything with a restore or revert screen gets an empty list and no error.

Inherited snapshot tags look like a snapshot-time copy rather than a link. Tag a VM and it's in scope immediately, but its existing snapshots keep tags: [] and stay invisible. So someone onboarded into a tag scope after their snapshots exist sees the VM and not its history.

Subscribing delivers no initial dump. Both streams sat on init and keepalives until something changed, so it's a delta feed and a client has to fetch the collection over REST and maintain it from events. Worth a line, since the natural assumption (at least to me, don't make that the rule for everyone) is the other one.

While I'm here: two smaller ones. Privilege action names aren't REST action names: shutdown:clean grants clean_shutdown, revert-snapshot grants revert_snapshot, and a mistyped action quietly gives you a privilege that grants nothing.
And the event: init frame's field is id, not connectionId (why did I think it was connectionId, no idea, I thought it was "natural"), which cost me a while of thinking the stream was dead when I was posting to /events//subscriptions.
Yes, I know, I should have read the documentation instead of experimenting in the dark, sending made-up field names in the wild.

One last thing: selector is optional, so a privilege created without one reads back as {id, resource, action, effect, roleId} with no hint the field exists.
I granted allow read on vm, saw all 11 VMs, read the object back, and (falsely) concluded the REST API had no object dimension at all.
It's all in the previous post and it's in the swagger, and of course, in the official documentation. Once again, I'm an innocent victim because I didn't RTFM.
I just never saw a privilege that had one. If a privilege echoed selector: null, or if the first example anyone met were a scoped one, I don't think I would have spent much time on that. Once again, my bad, didn't RTFM.

This was a small, targeted test, at best. I didn't have the intent to test what was brought up in this very thread, I just happened to tinkle with the REST API and ACL V2 for my PoC, so lots of things got untested.
Please, don't take it from me as settled: only tags: and id: selector forms, nothing on a second pool or a real multi-user deployment, and I have not checked what happens to a live subscription when the privilege itself changes rather than the VM's tags.

If you read me until there, you're brave, or have too much time on your hands.

Vates

Posts

Member List