Andrew Stuart writes:

 > So there is something to be said for a very simple Mailman Core
 > key/value store mechanism that would meet some simple needs. The
 > argument against this is “well you’re going to outgrow it pretty
 > quick anyway so why not immediately start with a more full featured
 > data store”.

I don't think you're going to outgrow it.  We have a sufficiently
flexible way to name resources (URI is a proof of concept) and
accesses, so a permission is just a triple (add a user).

One problem we face is secure communication between components for
identification and authentication purposes, which currently isn't
present in Mailman at all.  *That* could be a real problem, as there
may be embedded design decisions that induce a conflict between
efficiency and security (I don't think so, but that's the kind of
problem one typically runs into).  We also need an authorization
scheme which doesn't propagate excessive privilege across components,
but that can be done in principle by making permissions into
quadruples (add the component to distinguish privileges in one
component from privileges in another).

This kind of thing has been done for a long time (Kerberos), so I
guess the question is do we really need Kerberos, or can we get away
with something a lot less complex?

Finally we need the discipline to design and consistently implement a
system-wide authorization system.  That's undoubtedly the hardest

Mailman-Developers mailing list
Mailman FAQ:
Searchable Archives:

Security Policy:

Reply via email to