[Kolab-devel] Cyrus IMAP groups patch

[Jeroen van Meeuwen (Kolab Systems)]

Gunnar Wrobel wrote:
> 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.
> 

The need for this patch, I believe, was to enable parallel installations of 
Kolab (with OpenPKG) to have different sets of groups -but I wasn't there when 
it happened.

> 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?
> 

The group ID (or LDAP entry naming attribute to be a little more accurate) 
should not have to be in a fully qualified format.

Endangering myself of stating the obvious -for which I apologize in advance; A 
security group is something different from a distribution group, and both are 
based on the simplest form of a groupOfNames, groupOfUniqueNames and/or a 
groupOfUrls.

While they can be combined, by extending what is then just a normal group 
still with what makes that group a security group (posixGroup in this case) 
and/or a distribution group (now "kolabGroupOfNames"), the group may be given 
a mail: attribute should they need to become a targeted recipient.

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

I would like to see this patch being dropped from the upstream OpenPKG 
distribution as well, removed from CVS and all that, expunged from the wiki, 
closed in the issue tracker, starting at some or the other future milestone 
version.

-- 
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