Lucas Yamanishi wrote:
Hi everybody,

I've added some custom schema to my directory, but it's useless to me if
if I can't control read permissions on it.  This is obviously a little
tricky since (Free)IPA allows everybody to ready everything by default.
  With that, what's the best way to restrict access to user attributes?
Is there anything like this in the roadmap?

Right now there is are no plans to support deny ACIs natively in the permission plugin. That isn't set into stone, we just need some convincing.

The best way to do this is what you've done, manually creating ACIs. The problem with deny ACIs is they can get very hard to unwind when trying to figure out why things aren't working.

For the interim I've crafted some custom aci entries.  Where should I
put them?  Will they work?  Here they are:

aci: (targetattr =
   "attribute1 ||
   attribute2 ||
   attribute3")
  (version 3.0; acl "custom attributes base"; deny (all)
   (userdn = "ldap:///anyone"; and
   userdn != "ldap:///self"; and
   groupdn != "ldap:///cn=Read custom 
attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com");)

aci: (targetattr =
   "attribute1 ||
   attribute2 ||
   attribute3")
  (version 3.0; acl "custom attributes update"; allow (add, read, write, 
search, delete)
   (userdn = "ldap:///self"; or
   groupdn = "ldap:///cn=Manage custom 
attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com");)



We put all ACIs into the basedn, so for you dc=sesda2,dc=com.

This is going to be tricky since you want to delegate these but you can't create them natively. This means you need to create both the aci and the permission entry.

A sample permission would look like:

dn: cn=Read custom attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com
objectClass: top
objectClass: groupofnames
objectClass: ipapermission
cn: Read custom attributes

The ACIs need a little bit of work. The name of the aci needs to match the name of the ACI that permission is being granted to, with a prefix of permission:. So it should look more like:

aci: (targetattr =  "attribute1 ||  attribute2 ||  attribute3")
 (version 3.0; acl "permission:Read custom attributes"; deny (all)
  (userdn = "ldap:///anyone"; and
  userdn != "ldap:///self"; and
groupdn != "ldap:///cn=Read custom attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com");)

For the second ACI you don't need add and delete, those are entry-level permissions. You might want to add compare though.

We also tend to separate things you can do to your own entry from things you can do to others. So we would break this out into some selfservice ACIs and permission ACIs. Not saying what you're doing won't work.

rob

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

Reply via email to