[schooltool-dev] schooltool security policy enhancement?

[Tom Hoffman]

On 6/19/07, Paul Carduner <paulcarduner at gmail.com> wrote:
> On 6/19/07, Tom Hoffman <tom.hoffman at gmail.com> wrote:
> > On 6/18/07, Paul Carduner <paulcarduner at gmail.com> wrote:
> > > I would like to suggest some additions to SchoolTool's security policy.
> > >
> > > The allow directive should also accept attributes and class.  If a
> > > class is specified then you cannot specify an interface.  This would
> > > allow finer grained control of permissions.  Here is a usecase:
> > >
> > > Our Journal objects have a set of managers and a set of members, and
> > > these two attributes are likewise included in the IJournal interface,
> > > along with title and description.  You must have the schooltool.edit
> > > permission to modify any of these attributes, and schooltool.view to
> > > read any of these attributes.  I want to give teachers the
> > > schooltool.edit permission for everything in the IJournal interface,
> > > in which case the current security policy works fine.  I want to give
> > > students the ability to modify the title and description but not
> > > members or managers.
> >
> > Is that really necessary?
>
> Well, yes.  Actually the scenario is really a bit more complicated
> than I previously eluded to.  We actually have three types of
> journals: personal blogs, student journals (related to a section), and
> section forums.  At the moment the only thing distinguishing these
> different types of journals is their urls and the objects they are
> related to.  How they should *also* be distinguished is by their
> security.  students should have full control of their personal blog,
> medium control of their student journal and zero control of the
> section forum.  Is it really necessary to create three distinct
> classes with three distinct interfaces for each of these even though
> from an implementation perspective they are all exactly the same?
> That shouldn't be necessary.

On the other hand, is it necessary to complexify our security model
for just this case?  Is something like this going to come up again,
where we've got identical objects with slightly different security
policies?

--Tom