[dev] removeUserData permissions

[Karsten Fourmont]

Hi,

 > The only user that should be able to call removeUser() should be an
 > admin, and admins shouldn't have permission restrictions.

It's a bit more subtle.
Take mnemo_delete for example. It contains this:

     if (!array_key_exists($memo['memolist_id'],
		Mnemo::listNotepads(false, PERMS_DELETE))) {
         return PEAR::raiseError(_("Permission Denied"));
     }

listNotepad calls listShares of the share package. And this doesn't seem 
to return the complete list of shares for admins.

I think using listShares is the wrong way to check permissions. How 
should this be done?

Cheers,
  Karsten


listShares

Jan Schneider wrote:
> Zitat von Karsten Fourmont <fourmont at gmx.de>:
> 
>> Hi,
>>
>> in Turba, Nag, Mnemo and Kronolith we now have a removeUserData
>> function in the external api. This deletes all data (like private
>> address book and history) of a user for the respective app.
>> removeUserData is automatically called for each app by Auth::removeUser
>> when a user is removed.
>>
>> However this doesn't work as expected due to permission issues:
>>
>> when a user (let's call him "admin") removes a user "jondoe", "admin"
>> normally doesn't have write (delete) permission on "jondoe"s private
>> data. So the _delete and _list functions internally used by
>> removeUserData return "permission denied".
> 
> The only user that should be able to call removeUser() should be an 
> admin, and admins shouldn't have permission restrictions.
> 
> Jan.
> 
> --Do you need professional PHP or Horde consulting?
> http://horde.org/consulting/
> 
> 
> --Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org