docs for 1.4

[Angel Bosch Mora]

hi!

is there a way to access documentation for upcoming 1.4 release?

I would like to see specifically changes in ACIs as stated in this thread:

https://lists.fedorahosted.org/archives/list/[e-mail]...



thanks in advance,

abosch
-- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer
annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir
informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a
terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que
s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu
immediatament a l'adreca electronica de la persona remitent.
-- Abans d'imprimir aquest missatge, pensau si es realment necessari.

[William Brown]

THe syntax of the ACI’s is not changing, it is the default ACI’s we provide in our example
entries that will change.

These can be seen here:

https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/configurati...

This is how we apply the default example tree, and could serve as a good guide for ACI
design.

If you have a specific question though, I’d be happy to help! 

>  On 30 Apr 2019, at 22:15, Angel Bosch Mora
> <abosch(a)imasmallorca.net&gt; wrote:
>  
>  hi!
>  
>  is there a way to access documentation for upcoming 1.4 release?
>  
>  I would like to see specifically changes in ACIs as stated in this thread:
>  
>
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>  
>  
>  
>  thanks in advance,
>  
>  abosch
>  -- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer
> annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir
> informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a
> terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que
> s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu
> immediatament a l'adreca electronica de la persona remitent.
>  -- Abans d'imprimir aquest missatge, pensau si es realment necessari.
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Angel Bosch Mora]

>  If you have a specific question though, I’d be happy to help!
>  
I'm glad you offered :)

these are the attributes I'm currently using:

cn:
description:
displayName::
dn:
employeeNumber:
gecos:
gidNumber:
homeDirectory:
loginShell:
mail:
manager:
member:
memberOf:
objectClass:
petraSshPublicKey:
printer-make-and-model:
printer-more-info:
printer-uri:
sambaAcctFlags:
sambaNTPassword:
sambaPasswordHistory:
sambaPwdLastSet:
sambaSID:
shadowInactive:
shadowLastChange:
shadowMax:
shadowWarning:
sn:
uid:
uidNumber:


I want to change ACIs from old behaviour to white list aproach.
Should I include objectClass in the ACIs?

Do I need to create a deny-all as last ACI so everything that is not allowed gets denied?

In your blog you talk about a toolset to test ACIs, is that tool published somewhere?

best regards,

abosch



 
-- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer
annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir
informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a
terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que
s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu
immediatament a l'adreca electronica de la persona remitent.
-- Abans d'imprimir aquest missatge, pensau si es realment necessari.

[William Brown]

>  On 2 May 2019, at 21:28, Angel Bosch Mora
> <abosch(a)imasmallorca.net&gt; wrote:
>  
> > If you have a specific question though, I’d be happy to help!
> > 
>  
>  I'm glad you offered :)
>  
>  these are the attributes I'm currently using:
>  
>  cn:
>  description:
>  displayName::
>  dn:
>  employeeNumber:
>  gecos:
>  gidNumber:
>  homeDirectory:
>  loginShell:
>  mail:
>  manager:
>  member:
>  memberOf:
>  objectClass:
>  petraSshPublicKey:
>  printer-make-and-model:
>  printer-more-info:
>  printer-uri:
>  sambaAcctFlags:
>  sambaNTPassword:
>  sambaPasswordHistory:
>  sambaPwdLastSet:
>  sambaSID:
>  shadowInactive:
>  shadowLastChange:
>  shadowMax:
>  shadowWarning:
>  sn:
>  uid:
>  uidNumber:
>  
>  
>  I want to change ACIs from old behaviour to white list aproach.
>  Should I include objectClass in the ACIs? 
Generally I’d say you only need objectClass in aci’s where you have modification rights
occuring to ensure that the bounds of the modification are constrained.

If you are only adding ACI for read, then you can just have targetAttr for the attributes
required.

The best way to think of this is “what groups or roles need access to read what
attributes”.

So I’d write out something like:

everyone read -> a1, a2, a3 ….
admins read -> ….

Then I’d translate these to the read-aci’s you require



>  
>  Do I need to create a deny-all as last ACI so everything that is not allowed gets denied?
No, 389 defaults to deny, so anything “not list” will be disallowed. 

>  
>  In your blog you talk about a toolset to test ACIs, is that tool published somewhere?
Sadly not - some parts of it have become part of lib389 in the healthcheck module to find
targetAttr != rules, but the actual testing of “do these aci’s match expectations”, was
part of a previous work place, and I no longer have access.

Again, you can translate the above to something:

You would basically say “for each object in the directory”.

    if that object is in:
        everyone -> expect read on a1, a2 ….
        admins -> expect read on a3, a4 ….

Then I’d do the permission check (there is a 389 specific ldap extended op) that tells you
what rights you have other entries. I’d assert the expect matches each check, and
continue.


It was pretty overkill and kind of brute-force solution, but it is what lead to the
discovery of the aci issues with targetAttr != - I’d say if you don’t use targetAttr !=
you probably are already in a really good position to audit and understand the
interactions with your directory, so you may not need the tool at all. 


Hope this helps :) 


>  
>  best regards,
>  
>  abosch
>  
>  
>  
>  
>  -- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer
> annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir
> informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a
> terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que
> s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu
> immediatament a l'adreca electronica de la persona remitent.
>  -- Abans d'imprimir aquest missatge, pensau si es realment necessari.
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs