Restrict llLinksetDataReset() to scripts in the root prim
kiramanell Resident
Summary
llLinksetDataReset()
can currently be called by any script anywhere in a linkset. It deletes the entire linkset datastore, including entries created with llLinksetDataWriteProtected()
.This means that an unrelated script in any child prim can erase all protected data, despite being unable to read, overwrite, or individually delete those entries without the correct password.
Use case
Complex linksets are often assembled from independently scripted products. For example, a rezzer-managed building may contain linked furniture whose scripts were written under the assumption that the furniture owns its entire linkset.
Such a furniture script might reasonably call
llLinksetDataReset()
during initialization or a factory reset to guarantee an empty datastore. Once that furniture has been linked into a larger build, the same call silently destroys the datastore belonging to the entire build, including protected entries used by the rezzer.Conversely, protected entries cannot simply be made immune to resets. When two linksets are joined, their datastores are merged. The controller of the resulting linkset must remain able to remove protected data inherited from the other linkset, since it cannot be expected to know passwords chosen by unrelated products.
Proposed behaviour
Restrict
llLinksetDataReset()
so that it succeeds only when called by a script located in the current root prim.A call originating from a child prim should be ignored or otherwise fail without modifying the datastore.
This provides a natural authority boundary:
* A standalone product can reset its own datastore because its controller is in its root prim.
* After that product is linked beneath another root, its scripts can no longer erase the resulting linkset’s complete datastore.
* The controller in the new root can still wipe and rebuild the datastore, including removing protected records inherited during linking.
* Password protection continues to govern individual protected-entry operations.
Rationale
The linkset datastore is itself a property of the root prim. Giving only scripts in that prim authority to erase the entire datastore is consistent with that ownership model.
Currently, protected entries are protected against every destructive operation except the most destructive one. Restricting wholesale reset authority to the root prim would close that gap without making inherited protected entries impossible for the resulting linkset’s controller to remove.
Log In
Lucia Nightfire
We already hashed this out in the beta period. It was declared that coexistence/security of LSD in a mod env depends on protected keys, awareness and respect. Any creator who uses llLinksetDataReset() in a mod, multi-creator script/LSD env does not follow this ethic and should either be educated or discounted.
The best example where this ethic should already be in practice is AVSitter based furniture where, in many cases, can contain literally a dozen different creator's scripts, catering to various user addons/attachments.
It is too late to change the behavior of llLinksetDataReset() now as it will break existing content. We would, instead, need a root settable prim param that overrides LSD functionality.
kiramanell Resident
Lucia Nightfire See, the thing is: either the system relies on ethics, or on security. It's kinda pointless to have password protected entries, and then allow anyone to just wipe the entire database. It's like setting up a UNIX system, with users and passwords, but then let everyone perform an 'rm -rf /*' with root privileges. Allowing anyone to wipe the entire database, btw, as sugested, is not rude, or 'uneducated', but the sensible programming practice of initializing their databases. For instance, a rezzer could use llLinksetDataWrite() to write linkset data, now no longer in the Description field (the old way). So, my rezzer would neatly follow llLinksetDataWriteProtected() rules to write my own entries, but there's no way to guarantee a script in the linkset won't wipe the database clean; conversely, I might want to initialize the database myself to ensure space. The latter some might consider rude, but I see it as a choice.
If you made a piece of furniture relying on llLinksetDataWrite() data, then, with my proposal, you, as having made the root prim too, 'own' the database, and are guaranteed no one can wipe your database. The 'next owner' may decide to take ownership of the database from a new script in the root prim, or just by adding a new root prim. Without moralizing, that is just a choice (wise or unwise), and a natural effect of an object being mod. So, adding a new root prim will give the current owner of the linkset protected ownership of the database. They may decide to wipe the entire database (wise or unwise), but, more importantly, ensure no one else can perform such a destructive action.
Peter Stindberg
I am torn on this. I see where you are coming from, and your suggestion has merit. But if it would get implemented that way, it has the potential to break existing content. Would it be implemented as a new function, it would not be as effective.
I saw this problem early on, and "rmedied" it like this:
linkset_data( integer action, string name, string value )
{
if (action == LINKSETDATA_RESET)
{
llOwnerSay("A 3rd-party script has deleted my data storage, which is rude and speaks of the creator's poor development skills. Please remove the offending script (most likely the one you added last) as it will affect proper operation of this program.");
}
}
Bavid Dailey
I'd much prefer that llLinksetDataReset have password protection.
You're making a case for a universal wipe to be managed, and that makes sense. This isn't the way to do it, and I seriously doubt that breaking a lot of existing scripts will get much upoort from lindens.
kiramanell Resident
Bavid Dailey IllLinksetDataReset() cannot be password protected, as that would leave 'next owner' of linkset unable to wipe the database. Hence my proposal to restrict IllLinksetDataReset() to root-prim only. To quote myself: "Currently, protected entries are protected against every destructive operation except the most destructive one. Restricting wholesale reset authority to the root prim would close that gap without making inherited protected entries impossible for the resulting linkset’s controller to remove."