Posts made by sborrill

@olivierlambert I have a method I can use to workaround, yes, but there's a few things that violate POLA. It appears as ACL-only cannot be used to allow snapshotting because of the need to give admin-ish access to the SR. Using resource sets and self-service does work, but having to add users, not just groups they are in, to the resource set isn't great. I was unclear about why ACLs (i.e. visibility of a VM) disappeared when removing snapshots.

@sborrill said in Permissions for users to be able to snapshot:

(related question, can an existing VM be added to a self-service resource group?)

It appears not. The Web GUI makes it look like you can by allowing you to pick a resource set but you get the following error:

  "message": "the vm is not in a resource set

Note that despite this error, the VM has now been added to the resource set and can be snapshotted (if the user is explicitly a member of the same resource set - not just in a group that is)

@pdonias said in Permissions for users to be able to snapshot:

@sborrill Is the user a member of the resource set that you created?

The user was not explicitly a member, but was a member of a group that was. When I added the user to the resource set, I could snapshot, so it appears that the problem is that group inheritance does not work.

When I removed the user from the resource group (to double-check), it removed all the ACLs from the VM so that it was no longer visible to that user (or group). This looks like a bug. I had to use the share option against the resource set on the advanced settings to grant visibility again.

Does the VM belong to that same resource set?

Yes

Could you post the full error log that you get when the Self Service user tries to snapshot the VM?

vm.snapshot
{
  "id": "2af0ed72-7602-ad3a-142f-6f73e556d8b9"
}
{
  "code": 2,
  "data": {
    "permission": "operate",
    "object": {
      "id": "d0e48e5f-7012-d7c9-e300-0bd33f55d4d9"
    }
  },
  "message": "not enough permissions",
  "name": "XoError",
  "stack": "XoError: not enough permissions
    at factory (/opt/xen-orchestra/packages/xo-common/src/api-errors.js:21:32)
    at Object.assert (/opt/xen-orchestra/packages/xo-acl-resolver/index.js:132:17)
    at default.checkPermissions (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/acls.mjs:109:17)
    at Object.<anonymous> (file:///opt/xen-orchestra/packages/xo-server/src/api/vm.mjs:818:5)
    at Api.callApiMethod (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:307:20)"
} 

@sborrill said in Permissions for users to be able to snapshot:

(related question, can an existing VM be added to a self-service resource group?)

It appears not. The Web GUI makes it look like you can by allowing you to pick a resource set but you get the following error:

vm.set
{
  "resourceSet": "7hFH8vTa74k",
  "id": "44ebddd1-2a33-8775-033a-677b993b103e"
}
{
  "message": "the vm is not in a resource set",
  "name": "Error",
  "stack": "Error: the vm is not in a resource set
    at _class2.shareVmResourceSet (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/resource-sets.mjs:425:13)
    at _class2.setVmResourceSet (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/resource-sets.mjs:417:18)
    at runMicrotasks (<anonymous>)
    at runNextTicks (node:internal/process/task_queues:61:5)
    at processImmediate (node:internal/timers:437:9)
    at process.topLevelDomainCallback (node:domain:152:15)
    at process.callbackTrampoline (node:internal/async_hooks:128:24)
    at Object.<anonymous> (file:///opt/xen-orchestra/packages/xo-server/src/api/vm.mjs:530:5)
    at Api.callApiMethod (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:307:20)"
}

@pdonias I saw that, which is why I check that there was sufficient space defined in the resource set. I found a VM created using self-service cannot be snapshotted without granting Operator rights on the SR (so same behaviour as just using ACLs). The resource set does have the SR listed against it.

@olivierlambert I checked that there was sufficient space in the resource group for a full copy of the VM (assuming the snapshot would grow to the worst-case).

When the end-user views their list of VMs, it is not clear which are part of a resource set. I see that if you click on the details icon next to the number of items to display, then the resource set is displayed against each VM. This is a link, but I get Page not found when I click on the resource set name.

The reason I've been looking at self-service here is because of @julien-f saying that "I think your usage issues will be fixed by self service improvements." in issue 827 as a workaround for users needing Operator rights on the SR. It does seem that the ability to hide SRs from the UI for users as suggested by the OP in that issue would be a start.

@olivierlambert We have users that need the ability to mange and snapshot their own VMs without being able to affect/view other users' VMs or the infrastructure itself. Self-service has been recently implemented to allow them to create their own VMs as well as manage ones we have previously created for them which are covered by ACLs (related question, can an existing VM be added to a self-service resource group?)

I'm trying to understand what minimal permissions are required for a user to be able to snapshot a VM. I've read some github issues and https://xen-orchestra.com/docs/users.html#acls but the situation seems suboptimal.

User:

• Permissions = User
• member of ACL group that is Admin for relevant VMs
• does not have ACL rights over the VDI SR
• cannot snapshot

To allow snapshots, I had to give the user Operator rights over the VDI SR (which gives them far too many other rights).

Based on https://github.com/vatesfr/xen-orchestra/issues/827, I tried creating a VM using self-service as it suggested that might help, but I could not snapshot that either (until the user had Operator rights on the SR). How is self-service meant to help here?

xo-server 5.86.3, xo-web 5.91.2

UAnton created this issue in vatesfr/xen-orchestra

closed SR permissions #827

The LDAP plugin runs the query specified with {{name}} as the username you enter. It then uses the same value for the user account to create. This is OK for simple queries, but imagine you want to search by email address and/or account name while using a consistent name for the user account. It would be very handy to be able to optionally specify an LDAP attribute to extract and use for the user account (this is very similar to what NetScaler does for the SSO attribute).

For example, I have the following query:

(&(|(sAMAccountName={{name}})(mail={{name}}))(memberOf=CN=CloudConsole,CN=Users,DC=domain,DC=internal))

With this I can log in with either AD account name or email address (as long as I am a member of the specified group). Currently XO treats these as two separate accounts (with obvious associated problems for ACL duplication, etc.). I would like to specify that the XO username should be the sAMAccountName attribute

@julien-f Yep, exactly. Respond with 401 header if username or password are wrong (or not present). Probably allow for the realm to be configured too (not important for NetScaler).

I'd like to have the option for using basic http authentication rather than form-based authentication with Xen Orchestra (while still using LDAP for the actual backend authentication). This would allow easy single-sign-on through NetScaler by publishing it as an intranet resource without requiring Advanced/Enterprise licencing for SAML.