Re: I can't configure shared mailbox ACLs using LDAP information

2024-05-22 Thread Aki Tuomi via dovecot


> On 23/05/2024 04:42 EEST moso.mosoleu--- via dovecot  
> wrote:
> 
>  
> It shouldn't be impossible, but I've tried countless ways and not even 
> ChatGPT 4o was able to help me! :D
> 
> I use three LDIF files to get OpenLDAP ready for testing. In the first LDIF I 
> just modify the schema to add the associatedDomain attributes (then I could 
> configure the server to serve more than one domain). The second LDIF is to 
> add 4 objects to the schema that I use to differentiate accounts that 
> actually receive/send emails and have a password; another thing done in it is 
> to add a "groupOfUniqueNamesWithMail" object that allows the "mail" and 
> "mailEnabled" attributes that are then necessary to use in the entries 
> created in the "shared-mailboxes" OU. Finally, the third LDIF populates the 
> LDAP by creating OUs, user accounts and creating entries in 
> "shared-mailboxes" that serve to say which user accounts have access to which 
> other user accounts.
> 
> When I start the email server, sending and receiving emails works perfectly.
> 
> And mailbox shares work as expected if I manually use, for each share, the 
> command:
> 
> doveadm acl set -u ad...@mydomain.com.br INBOX user=use...@mydomain.com.br 
> lookup read write write-seen write-deleted insert post expunge create delete
> 
> But just as authentication works perfectly via LDAP, I believe there must be 
> a way to configure Dovecot to dynamically adjust ACLs via LDAP.
> 

Hi!

This has not yet been implemented in Dovecot.

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


I can't configure shared mailbox ACLs using LDAP information

2024-05-22 Thread moso.mosoleu--- via dovecot
It shouldn't be impossible, but I've tried countless ways and not even ChatGPT 
4o was able to help me! :D

I use three LDIF files to get OpenLDAP ready for testing. In the first LDIF I 
just modify the schema to add the associatedDomain attributes (then I could 
configure the server to serve more than one domain). The second LDIF is to add 
4 objects to the schema that I use to differentiate accounts that actually 
receive/send emails and have a password; another thing done in it is to add a 
"groupOfUniqueNamesWithMail" object that allows the "mail" and "mailEnabled" 
attributes that are then necessary to use in the entries created in the 
"shared-mailboxes" OU. Finally, the third LDIF populates the LDAP by creating 
OUs, user accounts and creating entries in "shared-mailboxes" that serve to say 
which user accounts have access to which other user accounts.

When I start the email server, sending and receiving emails works perfectly.

And mailbox shares work as expected if I manually use, for each share, the 
command:

doveadm acl set -u ad...@mydomain.com.br INBOX user=use...@mydomain.com.br 
lookup read write write-seen write-deleted insert post expunge create delete

But just as authentication works perfectly via LDAP, I believe there must be a 
way to configure Dovecot to dynamically adjust ACLs via LDAP.

The configuration in principle would be this:

acl_search_base = ou=shared-mailboxes,dc=mydomain,dc=com,dc=br

acl_search_filter = 
(&(objectClass=groupOfUniqueNamesWithMail)(|(uniqueMember=mail=%u,ou=system-accounts,dc=mydomain,dc=com,dc=br)(uniqueMember=mail=%u,ou=department-accounts
 
,dc=mydomain,dc=com,dc=br)(uniqueMember=mail=%u,ou=mailing-accounts,dc=mydomain,dc=com,dc=br)(uniqueMember=mail=%u,ou=person
 -accounts,dc=mydomain,dc=com,dc=br)))

acl_user = %u

Testing this filter on the command line with "ldapsearch" the expected results 
are returned. I mean, I enter an email address from a user account and the 
result is all the other user account email addresses that the first one would 
have access to.

Any charitable soul who is willing to help and needs more information, just say 
what you need and I will try to respond as quickly as possible.

I will place the content of the three LDIFs below.

[ 01-modify_domain.ldif ]

dn: dc=mydomain,dc=com,dc=br
changetype: modify
add: objectClass
objectClass: domainRelatedObject
-
add: associatedDomain
associatedDomain: mydomain.com.br
-
add: associatedDomain
associatedDomain: anotherdomain.com.br


[ 02-add_my_object_classes_to_schema.ldif ]

# Object class for system user accounts
dn: cn=SystemAccount,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: SystemAccount
olcObjectClasses: ( 1.3.6.1.4.1.9.1.1 NAME 'SystemAccount' DESC 'Object 
class for system accounts' SUP top AUXILIARY )

# Object class for department user accounts
dn: cn=DepartmentAccount,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: DepartmentAccount
olcObjectClasses: ( 1.3.6.1.4.1.9.1.2 NAME 'DepartmentAccount' DESC 'Object 
class for department accounts' SUP top AUXILIARY )

# Object class for mailing user accounts
dn: cn=MailingAccount,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: MailingAccount
olcObjectClasses: ( 1.3.6.1.4.1.9.1.3 NAME 'MailingAccount' DESC 'Object 
class for mailing accounts' SUP top AUXILIARY )

# Object class for person user accounts
dn: cn=PersonAccount,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: PersonAccount
olcObjectClasses: ( 1.3.6.1.4.1.9.1.4 NAME 'PersonAccount' DESC 'Object 
class for person accounts' SUP top AUXILIARY )

# Object class that allows groupOfUniqueNames to have a mail attribute
dn: cn=groupOfUniqueNamesWithMail,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: groupOfUniqueNamesWithMail
olcObjectClasses: ( 1.3.6.1.4.1.9.1.5 NAME 'groupOfUniqueNamesWithMail' SUP 
groupOfUniqueNames STRUCTURAL MAY ( mail $ mailEnabled ) )


[ 03-initialize_mydomain.com.br.ldif ]

### Create organizaitonal units

dn: ou=system-accounts,dc=mydomain,dc=com,dc=br
ou: system-accounts
objectClass: organizaitonalUnit
objectClass: top

dn: ou=department-accounts,dc=mydomain,dc=com,dc=br
ou: department-accounts
objectClass: organizaitonalUnit
objectClass: top

dn: ou=mailing-accounts,dc=mydomain,dc=com,dc=br
ou: mailing-accounts
objectClass: organizaitonalUnit
objectClass: top

dn: ou=person-accounts,dc=mydomain,dc=com,dc=br
ou: person-accounts
objectClass: organizaitonalUnit
objectClass: top

dn: ou=shared-mailboxes,dc=mydomain,dc=com,dc=br
ou: shared-mailboxes
objectClass: organizaitonalUnit
objectClass: top



## Create System User Accounts
#not related to a person
#can be accessed directly or indirectly by more than one person

dn: mail=ad...@mydomain.com.br,ou=system-accounts,dc=mydomain,dc=com,dc=br
uid: admin
userPassword: {SSHA}
displayName: My Domain - Admin
givenName: System
sn: Admin
cn: System Admin
mail: ad...@mydomain

Re: Problems using non-libc memory allocators

2024-05-22 Thread Aki Tuomi via dovecot


> On 22/05/2024 19:38 EEST bl0v3 via dovecot  wrote:
> 
>  
> Hey I was trying to use dovecot2 with a not libc based memory allocation 
> such as scudo or graphene-hardened or graphene-hardened-light but ran 
> into the issues I described in
> 
> 
> https://github.com/NixOS/nixpkgs/issues/313721
> 
> 
> I just wanted to mention this here as well as this behavior may suggest 
> a flaw in the memory allocation mechanism of dovecot2/anvil. I haven't 
> yet found the time to check the underlaying issue
> 
> as I'm quite busy rn. So I thought id just mention what I came across in 
> case this is actually unexpected or potentially even security relevant 
> mis/behavior.

Hi!

Looking at your issue it seems that graphene ones don't even make it to Dovecot 
code. 

Perhaps you should experiment with default_vsz_limit or per-process vsz_limit, 
maybe the default limit is too low for these allocators?

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


Problems using non-libc memory allocators

2024-05-22 Thread bl0v3 via dovecot
Hey I was trying to use dovecot2 with a not libc based memory allocation 
such as scudo or graphene-hardened or graphene-hardened-light but ran 
into the issues I described in



https://github.com/NixOS/nixpkgs/issues/313721


I just wanted to mention this here as well as this behavior may suggest 
a flaw in the memory allocation mechanism of dovecot2/anvil. I haven't 
yet found the time to check the underlaying issue


as I'm quite busy rn. So I thought id just mention what I came across in 
case this is actually unexpected or potentially even security relevant 
mis/behavior.

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org