On 04/10/2014 03:07 PM, Martin Kosek wrote:
On 04/10/2014 03:02 PM, Petr Viktorin wrote:
On 04/10/2014 02:58 PM, Martin Kosek wrote:
On 04/10/2014 01:46 PM, Petr Viktorin wrote:
On 04/09/2014 05:17 PM, Martin Kosek wrote:
On 04/09/2014 04:54 PM, Petr Viktorin wrote:
The meta-permissions.
:-)
Read access is given to all authenticated users. Reading membership info
(i.e.
privileges) is split into a separate permission.
Another permission is added that allows read access to all ACIs.
If we don't want to open that up for everyone, I could limit this to only
ACIs
containing "permission:". (Since old-style permissions store their
information
in ACIs, their ACIs need to be readable.)
If I read the notes from our DevConf discussion correctly, there are some
inconsistencies:
1) We decided to not do special membership permission for
permission/privilege/role permissions.
2) We decided to give read access to permissions, privileges and roles only to
member of a certain privilege. Is there any reason to not do that? IMO,
regular
users do not need to be able to read the permission/privilege/role
configuration of a FreeIPA installation to use it for IdM.
Martin
Updated. I plan to add all the RBAC-related read permissions to a single
privilege, "RBAC Readers". Or do we want more granularity by default?
Requires my patch 0514.
I was looking at the granularity we currently have with privilege and it is
mostly per FreeIPA function (Sudo Administrator or DNS Administrator), not per
IPA object (Sudo Command Administrator, Sudo Rule Administrator).
I would thus follow the same principle with RBAC and create RBAC Administrator
privilege which will cover read permissions for... permissions... privileges
and roles. In time, we will also add new write privileges there as they are
currently missing.
To sum it up, the patch works, I would just change the name of the privilege
and not focus it just on reading.
So to confirm, we want one privilege to cover both reading and writing?
IMO, yes.
Should I add new read permissions to existing "Administrator" privileges only,
instead of creating new "Reader" permissions?
I don't think so. The read permission we have been adding so far were targetted
on anonymous/all binds, thus according to our design, they cannot be added to
privilege anyway.
But if someone wants to restrict an object, he is free to change the permission
bind type to "group based" and assign it to a privilege.
In our case, I would assign read permission to privilege only if we decided to
make them group based, like RBAC or krbtpolicy ones.
Right, that makes sense. I'm asking about not having separate read
privileges when the permissions are group based. Based on Simo's other
mail we should have separate "Read" privileges.
Also IMO the read permissions should then be added both to the "Reader"
and "Administrator" privileges, since it doesn't make sense to be able
to write but not read.
--
Petr³
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
