Developers of Sympa

[Patrick von der Hagen <address@concealed>]

Am Donnerstag, den 17.01.2008, 06:33 -0500 schrieb Joe Vieira:
[...]
I believe Mark gave a good reply so there is just one thing I'd like to
comment on....

[...]
> 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)
The question is wheter or not you get a correct or "decent" design. And
if the design is implemented it might influence the quality of the daily
administration far more than the individual capabilities or
qualifications of the administrative staff.

The "design" consists at least of the software to be used, the
procedures and the policies that have to be followed. This environment
might support the admin and you just need some "normal human". For
example, it might write an audit-log to a central database anytime an
admin adds someone to a group, comprising an admin-id, date, time,
group-name and an identification of the affected member. It might even
realise that the group is labeled as "highly sensitive" and require an
approval of some manager first.
(An identity management-system should perform that. To write at least
something on-topic, I am using Sun Identity Manager, defined some roles,
assign roles to people and according to those roles their
email-addresses are added to database-tables, one for each list. Sympa
just includes a "select email-address from table" for each list and I
get an audit-log and workflows that require some managers approval for
sensitive lists "for free".)

The other extrem could be a system listing 20 "highly sensitive" groups
on a wiki-page and expecting the admin to first check this wiki-page, to
perform the change and to write some kind of audit-log to a text-file
stored on a central server. It is human nature that the admin will check
the wiki-page regularly first, less frequently later and after three
month will miss that a new group has been listed. And it is ordinary bad
luck that just the moment this admin has added someone to a highly
sensitive group, his boss will call him to an emergency meeting to
discuss the zero-day-exploit that currently threatens their customers
data. And of course, after that meeting the audit-entry is forgotten.

In the first example, the admin could not behave wrong. In the second
example, I'd never blame the admin. It would require supernatural powers
to do a good job in this given environment.

Now what you might design is something that just does not meet the
expectations of the normal administrative staff. For staff that is used
to handle list-subscriptions it would be hard to consider the
implications of adding someone to a list any time they perform their
ordinary daily routine. It would be hard to realise that adding someone
to the list "hr-staff" adds them to an LDAP-group which in turn is used
to grant access to sensitive data contained in the human-resources
application. It is hard, so they will get it wrong. I won't blame them.
On the other hand, staff used to grant or deny access to the hr-system
will find it so much easier to consider that granting access to the
hr-system implies granting to the mailinglist. It is unlikely they would
get it wrong.

So good usability will support a secure, high-qualitiy service. Bad
usability will kill both security and quality. ("Security and usability"
is a very good book by O'Reilly, I recommend it highly).


> 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.
If you understand my argumentation, consider all possible risks and
side-effects, develop and implement a design where you can controll all
possible problem, then you do an educates decision and I won't argue
with you.
But if such a "feature" would be added to sympa, I am sure many users
would not read our discussion, would do an uneducated decision and get
it wrong. You want to abuse sympa to perform some aspects of identity or
access manamgement, which is far away from the task it is designed for.
There are many products, even open source, which do a much better job
now than sympa will ever be able to perform.

Though I consider sympa to be the best list-management-software I have
seen, there are many aspects that might be improved and are in fact
realated to mailinglist-management. IMHO your idea is not.

I believe this discussion is hardly on-topic, so I'd prefer to take it
off the sympa-dev-list.

-- 
CU,
   Patrick.