Re: [Engine-devel] Permissions involved in using REST API
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
Re: [Engine-devel] Permissions involved in using REST API
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. But this distinction does not apply to API access, apparently; regular users cannot access the API at all as far as I can tell. I wouldn't mind giving API users 'admin' status if that's what it takes, but I'm concerned about the meaning of 'admin' changing in the future. I think the trouble here is that by doing it this way oVirt is presuming what the access policy is by baking rights into the 'admin' status. On a site-by-site basis the definition of 'admin' is going to vary. Thanks, -- Jonathan Daugherty Software Engineer Galois, Inc. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Permissions involved in using REST API
regular users *can* access the API, they just need to pass the filter:true in the request header. Oh, so it does. It wasn't clear from the earlier mention whether it applied only to admins and it never occurred to me to try it this way. Thanks! It seems to me this should be unnecessary, though. Can't the engine detect whether filtering should be enabled implicitly based on the user's status? Also: can we get this documented somewhere? Thanks! -- Jonathan Daugherty Software Engineer Galois, Inc. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Permissions involved in using REST API
- 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? Thanks! -- Jonathan Daugherty Software Engineer Galois, Inc. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
