[ApacheDS][Schema] Uncurbed cascade deletes could be disasterous

[Alex Karasulu <ak...@apache.org>]

Hi all,

I've been working on implementing this cascading control in the context of
the schema subsystem which
is highly specialized with cross references and dependencies to model
inheritance of attributeTypes and
objectClasses.  This is why a cascade option is needed while performing
modify operations.  I am realizing
that there are some limitations to doing this properly and at the same time
there are serious pitfalls in this
feature without it being curbed.

I don't think we should add this feature without having the ability to mark
schemas, and individual schema
elements as read-only (exposed in subschemaSubentry as X-READ-ONLY schema
extension).  Only the
administrator and owner of the schema should have the ability to revert the
read only flag.  Even the admin
should not be able to delete schema elements with or without the cascade
control present if any element
in the dependency chain is marked read only.

Now here is my dilema. I would never allow a production grade release
without having these checks in
place.  Just imagine what would happen if the admin deleted the 'top'
objectClass or the 'name'
attributeType: a large amount of the schema would be blown away and the
server would be rendered
useless although blowing away the schema partition folder will recreate it
with the defaults.  Regardless
should we allow this feature in this (non-production) feature release with a
warning.

Another option is to disable cascade deletes for now and just support
cascading modifications?

Thoughts?

Alex

Re: [ApacheDS][Schema] Uncurbed cascade deletes could be disasterous

[Emmanuel Lecharny <el...@gmail.com>]

Hi Alex,

this is a complex issue, and we won't have easy solution.

First point, we have to stress the fact that this is not a 'stable'
version, or as we discussed it a few months ago, this is an
intermediate version. So implementing a partial solution is not really
a problem.

This being said, here are some thoughts, comments inline :

> I don't think we should add this feature without having the ability to mark
> schemas, and individual schema
> elements as read-only (exposed in subschemaSubentry as X-READ-ONLY schema
> extension).  Only the
> administrator and owner of the schema should have the ability to revert the
> read only flag.  Even the admin
> should not be able to delete schema elements with or without the cascade
> control present if any element
>  in the dependency chain is marked read only.

The main problem is that we have no idea about the potential impact of
a schema modification before we see its real impact on an existing
base. Now, we also must assume that the admin 'knows' what he is doing
(this is a wish ;). I have read a discussion about the removal of the
m-oid attribute and its consequences. I felt like it was pretty much a
discussion about what will happen to someone who play russian roulet
with 6 bullets in the gun... Brain damages will be at least severe,
but there is no way to fix the gun to avoid such damages !

Ok, I agree that the meta-schema should _not_ be writable. And I also
agree that the core schemas should _not_ be writable either. So let's
use this feature quickly.


> Now here is my dilema. I would never allow a production grade release
> without having these checks in
> place.  Just imagine what would happen if the admin deleted the 'top'
> objectClass or the 'name'
> attributeType: a large amount of the schema would be blown away and the
> server would be rendered
> useless although blowing away the schema partition folder will recreate it
> with the defaults.

The admin who delete the 'top' objectClass should be punished for his
sins ! Ok, seriously, there are some objects which need to be
protected. We may add a dsaOperation attribute in such objects to
protect them against destruction. And we can also create a control if
we _really_ need to destroy those objects for some reason (a
combinaison of a delete operation and this specific control will allow
the desctruction). wdyt ?


>
> Another option is to disable cascade deletes for now and just support
> cascading modifications?

I would suggest that we allow deletes and modifications first, and
restrict them later. It would be so good if we have a way to keep an
history for the schema (a kind of svn repo inside the server), and
allow the admin to revert his changes back to a stable version ! I
guess this could be possible, but I don't know how much it could cost
to implement such a feature !

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com