On 11/07/2013 07:20 PM, Jonathan Daugherty wrote:
- Is this expected behavior? Is there some smaller (less
permissive) change in privileges I can use to bring about the same
behavior?
Yes. That's the expected behavior. However, when accessing the API you
can set the "filter" header parameter to "true", and that will get you
to the user-level API. Let me know if you need technical assistance
with that.
Thanks! The Filter header works for me.
While it's good to have some means of controlling which users can access
the API, I think that the current means is very misleading and alarming.
It's misleading because it presumes I think admin users are the only
ones who should access the API (I don't) and it is alarming because if I
have to set the admin bit on users to let them do this, I'm not sure
whether I'm inadvertently granting them rights to do other things (I
don't want to). In any case it certainly isn't how I would imagine some
people think about this sort of use case; for example, if I want my
Jenkins CI system to be able to talk to oVirt via the API, I don't think
of that as administrative access.
I would love to see a new permission checkbox added, e.g., "REST API
access", which I could check or uncheck on a per-user or per-group
basis. Unfortunately I can't volunteer to do this work myself and even
if I could it isn't yet clear whether such a new feature somehow
conflicts with other design decisions the engine developers have made.
So now my next question is: if I create an admin account without any
privileges as I have described, are there any hidden privileges other
than API access which I need to know that user has?
the main difference between an 'admin' and a 'user' is that admin has
read-only permission to see all objects in the system, and a user can
only see objects they have permissions on.
the 'right' way should have been that the default access would be for
user mode, and an admin would have to set 'admin:true' rather than user
set 'filter:true'. but admin api pre-dates user mode, and we didn't want
to break backward compatibility.
michael/juan - thoughts on how to make this more, well, sensible?
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
