View Issue Details

IDProjectCategoryView StatusLast Update
0005307SOGoWeb Mailpublic2021-04-29 21:02
Reportermat1010 Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Platform[Server] LinuxOSRHEL/CentOSOS Version7
Product Version5.1.0 
Summary0005307: SOGo mail folder ACLs not editable with IMAPLoginFieldName
Description

We are using Dovecot 2.3.14 as IMAP backend and MySQL 5.7 as user backend.

The user schema in this project requires that we set the IMAPLoginFieldName to a different field than LoginFieldNames, since dovecot uses some "internal" name to seprate the users and domains on a folder level which SOGo, and also the users, do not know about.

The translation of the "known" mail address to the internal username, which is used for the ACLs, works fine, we are able to initially set ACLs and also remove them. Unfortunately, once the ACLs are set, we are not able to see the active ACLs when opening the "Sharing" menu. We see the permitted users in the list, but selecting the user does not expand the list of ACLs for that user, so we can only completly remove the permissions and re-apply them afterward - see attached screenshot.

The getacl IMAP command seems to properly go through and receives a result:
C[0x56548caf8bc0]: 7 getacl "shared.<internal_username>"
S[0x56548c8204a0]: * ACL shared.<internal_username> shared.<permitted_internal_username> akxeilprwtscd

On another setup, where the username for the imap login and the sogo login is the same, this works without any issue.

Is this a known issue / is something else required to get the ACL listing working in the UI?

This is the domain specific SOGo configuration:

example.com = {
  SOGoUserSources = (
    {
      type = sql;
      id = example.com;
      DomainFieldName = domain;
      viewURL = mysql://foo:bar@127.0.0.1:3306/mail/sogo_auth_view;
      LoginFieldNames = (mail, c_uid);
      IMAPLoginFieldName = imap_uid;
      canAuthenticate = YES;
      isAddressBook = YES;
      displayName = &quot;Users&quot;;
      userPasswordAlgorithm = blf-crypt;
      KindFieldName = kind;
      listRequiresDot = NO;
    }
  );
  SOGoIMAPServer = &quot;imap://imap-backend:143/?tls=YES&tlsVerifyMode=none&quot;;
  SOGoSMTPServer = &quot;smtp://imap-backend587/?tls=YES&tlsVerifyMode=none&quot;;
  SOGoSieveServer = &quot;sieve://imap-backend:4190/?tls=YES&tlsVerifyMode=none&quot;;
};
TagsNo tags attached.

Activities

mat1010

mat1010

2021-04-28 20:44

reporter  

Screenshot_20210428_170950.png (25,875 bytes)   
Screenshot_20210428_170950.png (25,875 bytes)   
mat1010

mat1010

2021-04-29 09:07

reporter   ~0015230

A found a "fix" for the issue. If I add the value of IMAPLoginFieldName to the LoginFieldNames, SOGo seems to be able to match the internal user with the user that is used to login. My change looks like following:

  • LoginFieldNames = (mail, c_uid);
  • LoginFieldNames = (mail, c_uid, imap_uid);

Not sure yet if this has any other unexptected side effects.

mat1010

mat1010

2021-04-29 21:02

reporter   ~0015232

The above mentioned "fix" seems to work as expected without side effect.

Is there a technical reason that this is required? SOGo should be able to find the matching c_uid of a user with the returned username value by the imap backend with the "getacl" command, since SOGo could find the matching user by his IMAPLoginFieldName, or am I missing something?

if it is intended that the value of IMAPLoginFieldName also has to be added to the list of LoginFieldNames, I think this should be mentioned in the documentation

Issue History

Date Modified Username Field Change
2021-04-28 20:44 mat1010 New Issue
2021-04-28 20:44 mat1010 File Added: Screenshot_20210428_170950.png
2021-04-29 09:07 mat1010 Note Added: 0015230
2021-04-29 21:02 mat1010 Note Added: 0015232