On 06/19/2014 12:52 PM, Petr Viktorin wrote:
> I'll address the other issues separately.
> 
> On 06/18/2014 05:46 PM, Martin Kosek wrote:
>> 3) I hit one issue when I open the Web UI host tab, I get "Insufficient 
>> access:
>> No such virtual command" error triggered by "cert-show" command.
>>
>> We will need to add the permission "System: Read Virtual Operations" that 
>> Honza
>> is creating also to "Host Administrators" to fix that part.
> 
> I'm not familiar with Honza's effort, but that seems right.
> I'm curious, why don't we just allow reading virtual operations by anybody? It
> seems to me they're the same in every IPA installation, what's there to hide?

They are indeed the same. This is an old (very old) mean to check access when
ACI cannot be used. I admit it is a bit clumsy.

I agree that we should indeed allow reading the list of virtual operations as
the list can be retrieved from our git anyway. The virtual operations do not
even show list of it's members as permissions hold it, so it really should not
leak any sensitive information.

> Anyway, I poked around in how it works now: for cert-show you need write 
> access
> to the objectClass of the "retrieve certificate" virt op entry. So that right
> you can actually remove the "ipaVirtualOperation" objectClass.
> Aand the new "Anonymous read access to containers" ACI has a
> (!(objectclass=ipaVirtualOperation)) filter, so any user privileged for a virt
> op can allow everyone see that virt op).
> Shouldn't we base the check on some other attribute instead?
> 
> And curiously, for cert-find there is no virt op based access check.

I think we should eventually invent something better than current virtual
operations. For now (4.0), we should do something simple and straightforward.
The simplest thing to do is stick to the old behavior, i.e.:

1) Remove the (!(objectclass=ipaVirtualOperation)) part of the filter (should
improve performance, right?)
2) Remove the ipaVirtualOperation objectclass again from the virtual operations
as it would be useless after change 1)

Martin

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to