add check to verify at least System.View permissions when using sessionfiles

[mlueckert]

Hi datamuc..

We encounter the following issue when using the --sessionfile feature.

We are using a monitoring user for accessing our esxi hosts. It can happen, that the user is created on the ESXi hosts without enough permissions and the permissions are configured some minutes/hours later. In that case, the session that will be initiated and used is valid but it has not enough permissions.

In that case, the check will fail with an unhandled exception.

UNKNOWN - Unhandled exception: (vim.fault.NotAuthenticated) { dynamicType = <unset>, dynamicProperty = (vmodl.DynamicProperty) [], msg = 'The session is not authenticated.', faultCause = <unset>, faultMessage = (vmodl.LocalizableMessage) [], object = 'vim.PerformanceManager:ha-perfmgr', privilegeId = 'System.View', missingPrivileges = (vim.fault.NoPermission.EntityPrivileges) [] }

The problem with that is, that the session will never be recreated with the new permissions and we have to manually delete the sessionfiles.

This PR just adds a call to a method of the service_instance object that requires at least System.View permissions. If these permissions are missing we get an exception and will try it again with username password.

I just added this to our environment and the session issues are gone.

Feel free to add your thoughts.. would be great to have this fixed in your release.

Regards, Marc

[datamuc]

Hi Marc,

I don't like that it adds an extra HTTP call to every check for such an edge case. Maybe it's better to delete the session file on any unhandled errors instead?

Isn't ideal either, only one faulty check will delete the shared session file all the time, but that would be at least temporary until the situation is fixed. But I don't like that very much either.

I will think a bit more about that.

[mlueckert]

Thank you for you inputs, I agree with them. Deleting the file on every error could be an option I also though, but what I like with my approach is that it happens during the session initialization phase and not later and that it does not add additional logic. I also first thought this is an edge case.. but after having multiple hosts that were stuck in an UNKNOWN state and I had to manually intervene I thought we have to fix that.

[datamuc]

I think the right place to do this is the about check. We can add an option to also check for the system.view permission and delete the session file there if it fails.

[datamuc]

Hi @mlueckert,

would that suit your needs? 19a6436844a4cbeb68f78d7e014ceb105452532d

[mlueckert]

Hi @datamuc

I like it, thank you for handling this edge case.

[datamuc]

implemented with 19a6436844a4cbeb68f78d7e014ceb105452532d