5:34 p.m.
Hi all,
I'm interested in setting up a non-administrative user account to be
used to access the oVirt REST API. I have a user who is testing this
functionality by integrating some Vagrant-related software to talk to
oVirt. The user's oVirt account is a non-admin account with enough
privileges to create and modify VMs on one of my clusters.
What we found is that the account is unable to make requests to, say,
/api/vms
(he gets 401 or 404 responses) and instead gets a response indicating
that the account has "insufficient permissions." My engine.log says of
the access only this:
2013-11-06 14:50:28,158 ERROR
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource]
(ajp--127.0.0.1-8702-13) Operation Failed: query execution faile
d due to insufficient permissions.
and in server.log I have see Java tracebacks involving this[1]:
2013-11-06 14:50:28,159 WARN
[org.jboss.resteasy.core.SynchronousDispatcher]
(ajp--127.0.0.1-8702-13) failed to execute:
org.ovirt.engine.api.restapi.resource.BaseBackendResource$WebFaultException
Later we found that assigning an Admin role to the user's account at the
data center level with no permissions enabled permitted API access. So
the user was able to make requests to /api/ URLs and get data and was
able to log into the oVirt administration portal but was unable to take
further action.
So my questions are:
- Is this expected behavior? Is there some smaller (less permissive)
change in privileges I can use to bring about the same behavior?
- Is there some place where such behavior is documented? I couldn't
find any. The documentation on permissions on the RHEV docs only
mentions the overall impact of using specific roles and permissions
and says nothing about API access consequences or "Admin" roles with
no permissions.
My initial assumption was that any user with credentials would be able
to make API requests, but that the corresponding API responses would be
filtered based on what the user had privileges to see just as with the
User Portal.
Thanks!
[1] A full trace can be found at http://pastebin.com/czcfQkYL
--
Jonathan Daugherty
Software Engineer
Galois, Inc.
2:26 a.m.
----- Original Message -----
From: "Jonathan Daugherty" <jtd(a)galois.com>
To: engine-devel(a)ovirt.org
Cc: "Trevor Elliott" <trevor(a)galois.com>
Sent: Thursday, November 7, 2013 1:34:01 AM
Subject: [Engine-devel] Permissions involved in using REST API
Hi all,
I'm interested in setting up a non-administrative user account to be
used to access the oVirt REST API. I have a user who is testing this
functionality by integrating some Vagrant-related software to talk to
oVirt. The user's oVirt account is a non-admin account with enough
privileges to create and modify VMs on one of my clusters.
What we found is that the account is unable to make requests to, say,
/api/vms
(he gets 401 or 404 responses) and instead gets a response indicating
that the account has "insufficient permissions." My engine.log says of
the access only this:
2013-11-06 14:50:28,158 ERROR
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource]
(ajp--127.0.0.1-8702-13) Operation Failed: query execution faile
d due to insufficient permissions.
and in server.log I have see Java tracebacks involving this[1]:
2013-11-06 14:50:28,159 WARN
[org.jboss.resteasy.core.SynchronousDispatcher]
(ajp--127.0.0.1-8702-13) failed to execute:
org.ovirt.engine.api.restapi.resource.BaseBackendResource$WebFaultException
Later we found that assigning an Admin role to the user's account at the
data center level with no permissions enabled permitted API access. So
the user was able to make requests to /api/ URLs and get data and was
able to log into the oVirt administration portal but was unable to take
further action.
So my questions are:
- 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.
- Is there some place where such behavior is documented? I
couldn't
find any. The documentation on permissions on the RHEV docs only
mentions the overall impact of using specific roles and permissions
and says nothing about API access consequences or "Admin" roles with
no permissions.
Unfortunately I didn't find any documentation on that on the ovirt wiki.
Michael - do you know if such documentation exists somewhere?
My initial assumption was that any user with credentials would be
able
to make API requests, but that the corresponding API responses would be
filtered based on what the user had privileges to see just as with the
User Portal.
Thanks!
[1] A full trace can be found at http://pastebin.com/czcfQkYL
--
Jonathan Daugherty
Software Engineer
Galois, Inc.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:20 a.m.
> - 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.
6:18 a.m.
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?
12:08 p.m.
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.
12:11 p.m.
On 11/11/2013 01:08 PM, Jonathan Daugherty wrote:
> 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.
regular users *can* access the API, they just need to pass the
filter:true in the request header.
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,
12:16 p.m.
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.
12:18 p.m.
On 11/11/2013 01:16 PM, Jonathan Daugherty wrote:
> 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?
idea is an admin can also be a user. the default should just have been
reverse behavior if we could.
Also: can we get this documented somewhere?
it should be, but if you can't find it easily on the wiki, please create
a page elaborting this.
3825
days inactive
3830
days old
7 comments
3 participants
participants (3)
-
Itamar Heim -
Jonathan Daugherty -
Oved Ourfalli