[Opensim-dev] fyi: Some ExternalChecks method changes and a question about public interface policy

[Melanie]

Some change there does seem in order. The current implementation is 
overclumsy, it requires lots of code to be added for every perms 
check handler.
However, this is an extremely ticklish area, we need to be careful 
that anything that changes behaviors is changed so it would be 
denied rather than allowed, so no privilege escalations sneak in.

I have done lots of work there and would be happy to discuss 
possible interface structures.


Melanie


Frisby, Adam wrote:
> Should we follow suit to PermissionsModule interfaces as we are doing with IClientAPI and make it a collection of possible interfaces?
> 
> Adam
> 
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>> bounces at lists.berlios.de] On Behalf Of Justin Clark-Casey
>> Sent: Thursday, 13 November 2008 1:37 PM
>> To: opensim-dev at lists.berlios.de
>> Subject: [Opensim-dev] fyi: Some ExternalChecks method changes and a
>> question about public interface policy
>>
>> For everybody's information, in the last few commits I renamed the
>> existing ExternalChecks.CanCreateInventory,
>> CanDeleteInventory, etc. to CanCreateObjectInvnetory,
>> CanDeleteObjectInventory etc.
>>
>> My justification was that they were accepting an object id argument, so
>> I assumed that they were intended for objects
>> only rather than user inventories.  They also didn't appear to actually
>> be being used anywhere in the code (though I
>> have just added a call to the create one).
>>
>> I then added the following set of external hooks specifically for user
>> inventory
>>
>> bool ExternalChecksCanCreateAvatarInventory(int invType, UUID userID)
>> bool ExternalChecksCanCopyAvatarInventory(UUID itemID, UUID userID)
>> bool ExternalChecksCanCopyAvatarInventory(UUID itemID, UUID userID)
>> bool ExternalChecksCanDeleteAvatarInventory(UUID itemID, UUID userID)
>>
>> However, I appreciate that there are some external modules that
>> implement the previous CanCreateInventory, etc.
>> permission checks, even though they aren't yet used in the OpenSim
>> code.  In particular, there appear to have been some
>> interpretations of CanCreateInventory, etc. as applying to both objects
>> and users.  In the user case, the objectID
>> argument passed in would have been null (it would have been helpful to
>> have some code documentation on this assumption,
>> but I digress :)
>>
>> But there is a larger issue here.  Namely, to what extent should our
>> public interfaces be fixed at this stage?  There is
>> an argument that we should avoid changing these as much as possible.
>> If they do have to be changed, then we should at
>> least make an announcement before any changes.
>>
>> The permissions module is particularly sensitive, since a change in
>> semantics may impact people's content.
>>
>> My personal view is that at this stage in our code evolution (until we
>> reach 1.0 or very near to it), all interfaces are
>> fair game for changes that aren't completely gratuitous.  Third party
>> modules simply have to adapt.  I feel that even
>> having to pre-announce changes is a significant brake on development.
>>
>> In addition, it's always going to be the responsibility of OpenSim
>> users to make sure they are happy with the code
>> before they put it into production.  At the top of every file we
>> disclaim any liability for its actions.  A good set of
>> unit tests would help build assurance as to the stability of the
>> permission module's functionality.
>>
>> I'd like to know what views there are on this matter of public
>> interfaces, particularly from other core developers.  If
>> we do want to restrict public changes then I thank that we should have
>> a well-understood written process.
>>
>> Apologies for the long post.
>>
>> Regards,
>>
>> --
>> justincc
>> Justin Clark-Casey
>> http://justincc.wordpress.com
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
>