Developers of Sympa

[Mark K <address@concealed>]

On Thu, 17 Jan 2008 06:33:58 -0500
Joe Vieira <address@concealed> wrote:

> >Imagine a restricted resource granting access based on
> >LDAP-group-membership and a responsible person expecting to be asked
> >for approval before granting access. Someone else doesn't know about
> >such> policies or the implications about adding someone to a
> >such> mailinglist and
> >suddenly someone gets access to a restricted resource who should not.
> 
> That's where robust design comes in, your sympa service account
> shouldn't have access to add people to groups which are restricted or
> sensitive.  what if on the flip side you want to grant people access
> to things based on what mailing lists they're in.  say you've got a
> blog or something, and you only want people on the mailing list to be
> able to log into the blog....how can you do that currently?  you need
> to know about ALL subscribers.
> 
If LDAP feeds mailing lists via include2 then that's how you know all
the subscribers.  It's always the same as the LDAP group.  You don't
need the mailing list to feed LDAP for that to happen.


> also, what if someone gets manually added to a mailing list (via
> sympa) and then gets added to the ldap group  later by an automated
> process (they added a class or something)?  does sympa handle that or
> does the user get two copies of the mail?
> 
In a case like that you would not allow subscription (subscribe.closed
scenario) since all members would be included from LDAP.

> >You would probably only know "at some time someone added a
> >group-entry" and you are expected to find out "who did the change",
> >"who approved the change" and "when did it happen".
> >You can only reliably do that if you restrict yourself to ONE point
> >of change where you can provide some kind of audit-log. Digging
> >around "it might have been the help-desk... but I can't find
> >anything in their logs.... it might have been sympa... but I don't
> >keep sympa-logs long enough... it might have been an LDAP-admin, but
> >they don't even make a note when changing a group-entry in the
> >directory..." is really ugly.
> 
> I don't think applications should be responsible for making sys
> admins or design engineers responsible, and they certainly can't
> enforce policies regarding log retention and such...the sys admin /
> engineers need to design the whole thing correctly...(good software
> isn't a replacement for good admins)
> 
yes, but when you let people use your software, they do bad things :).

> 
> i certainly understand the logic behind NOT letting tons of
> applications change things, however those are design considerations
> of individual infrastructures, some infrastructures might need it, in
> others it might mess everything up. I think that the ablity to write
> back to datasources is important, i mean default it to off, and have
> it require configuration to work correctly.  heck make it possible
> for manual additions to groups to actually be added to another group,
> and build a secondary query to include them.  that way they are
> separate but all in one datasource.
> 
Well, sympa is not designed to be a database management tool.  For
another example of what Patrick is trying to point out I'll draw from
my own experience.  Back in the old days, I maintained a majordomo
listserver that had a mailing list for each UNIX group auto-generated
daily.  Those lists were completely locked down.  They reflected the
membership of the UNIX groups.  I did not even try to allow addition of
members to the mailing list to be reflected back to the UNIX groups.
Not because of any technical hurdle, but because there were certain
checks and balances to getting added to a UNIX group that had nothing
to do with mailing list membership.  UNIX groups allow access to files
and processes. Mailing lists don't.
It is not a problem for "letting tons of applications change things"
but those things should have the same 'purpose.'  Giving someone access
to a mailing list has many fewer implications than adding someone to a
LDAP group that may be tied into a naming service, Web access, DB
access, application access.  Occam's razor applies to software design,
too.  KISS.  


> 
> thanks for the discusses these are proving very helpful,
> 
> Joe Vieira
> UNIX System Administrator
> Clark University
> 
> 
> 


-- 
Mark K