[Kolab-devel] Cyrus IMAP groups patch

[Gunnar Wrobel]

Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

> Gunnar Wrobel wrote:
>> Zitat von Thomas Arendsen Hein <thomas at intevation.de>:
>> > In short: We don't need the groups patch upstream,
>>
>> I don't think Jeroen wanted to get the groups patch upstream. He also
>> wants to avoid it and I think he suggested to do so via PAM.
>>
>
> Indeed I do not want to upstream this patch, and in fact I want to drop it
> from Kolab as well.
>
>> > we probably want SASL to know about the group of names in LDAP.
>>
>> ... and in turn Cyrus IMAPD to use SASL for group lists. It is
>> mentioned in the issue you linked so I think you know that but I just
>> wanted to highlight that the resulting patch is a two step appraoch
>> and probably would not be to easy.
>>
>> @Jeroen: If I understood you correctly you were suggesting that we
>> could feed Cyrus IMAPD with alternate group information via PAM. Did I
>> indeed understand you correctly? How could such an approach look like?
>> I'm no PAM expert and it would cost me some research to see if that
>> should be possible or not.
>>
>
> SASL is an authentication layer, not a general user/group information or
> authorization layer (although it can be used to limit whether a user
> successfully authenticates by enforcing membership of a certain group). Long
> story short, SASL cannot (or actually, should not) be used for general group
> information, and creating a plugin that uses SASL's LDAP capabilities is just
> too inefficient (both in development as well as in actual implementation).
>
> There is a simple alternative, which in my opinion is also very acceptable;
>
> Obtaining group information from LDAP does not include the entire system
> authenticating to LDAP. It merely requires that NSS is aware of where groups
> reside;
>
> [root at test90-1 ~]# getent group sales
> [root at test90-1 ~]# vim /etc/nsswitch.conf
> (...
>     make sure the groups: line includes ldap
>     ...)
> [root at test90-1 ~]# getent group sales
> sales:*:507:vanmeeuwen
> [root at test90-1 ~]#
>
> I'm not sure how this, having been configured system-wide (admittedly) can be
> mutually exclusive with anything else that may be going on on said system?

Well, as far as I can tell this was the original problem that led to  
the patch in the first place. So if I understand it correctly at the  
moment: We do not really have an alternative for this patch with  
regard to OpenPKG.

Then again: We agree that we don't want to stick to OpenPKG forever.  
So supporting that patch in OpenPKG for a while longer should be just  
fine. We already did for years so this won't hurt.

Back to the native ports: My impression would be that it is okay to  
follow Jeroens suggestion. At least as long as the groups always have  
an ID in mail format. Which they do at the moment. So chances to mix  
this up with system accounts are low. Do people agree? Thomas,  
Mathieu, do you think this is okay?

In that case I'd suggest keeping the patch in OpenPKG but switch to a  
system based approach in the native ports.

Cheers,

Gunnar

>
> --
> Jeroen van Meeuwen
> Senior Engineer, Kolab Systems AG
>
> e: vanmeeuwen at kolabsys.com
> t: +316 42 801 403
> w: http://www.kolabsys.com
>
> pgp: 9342 BF08
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



--
Gunnar Wrobel
Developer, Kolab Systems AG

e: wrobel at kolabsys.com
t: +49 700 6245 0000
w: http://www.kolabsys.com

pgp: 9703 43BE

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.