Developers of Sympa

[Joe Vieira <address@concealed>]

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

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?

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


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.


thanks for the discusses these are proving very helpful,

Joe Vieira
UNIX System Administrator
Clark University