[development] Changing Roles (was Deleting Cached Permissions)

[Ron Parker]

On Aug 28, 2007, at 4:04 AM, Karoly Negyesi wrote:

> Changing user_access could lead to very obscure and hard to debug  
> priviledge escalation holes: some code may make presumptions about  
> if a page is allowed by menu then certain permissions are set which  
> might not be true if you fiddle with roles on the fly. Saying that  
> this does not happen currently won't change the fact that it could.

Let me again make it crystal clear: The user_access() patch I submitted here http://drupal.org/node/170524 does NOT change user roles or alter current user_access functionality or permissions in any way.  It simply resets the permissions calculated by user_access.  It clears the cache.  AND, it's optional!  You have to send the command: user_access('', NULL, TRUE) in order for it to execute, otherwise, user_access is not affected at all.  So, if you don't need it, you don't use it.

> Just overdefine the menu item that you want to change and define  
> your access mechanism. Because node/add is defined as cached you  
> can put your menu definiton in !$may_cache with the same path -- it  
> will overwrite the original definition. In Drupal 6, you want to do a

The OG User Roles (OGR) module basically performs most of the functionality most users need it to do now, and with no patches to the core module, and no "overdefinitions" in hook_menu.  It utilizes $user->roles because that's what $user->roles was designed to do: Tell you what permissions a user has.  This whole current issue arose because I discovered user_access() was caching permissions and thus causing a problem with OGR and the upload.module. And, there was no way to clear this cache like there is practically everywhere else in Drupal. I further realized that this same issue had caused compatibility problems with the BuddyList, OG Forum and Relativity modules which, as you suggested, I wrote around to resolve.  

However, at some point, it seems ridiculous to keep trying to write customized code for every module where I have this problem when the simple solution is to reset the cache, a rather harmless option that should be available everywhere that Drupal creates a cache (including user_access()).

I know you don't want to support role changes on the fly, but killing Peter to spite Paul doesn't seem like a logical way to do it.

-ron

-- 
Ron Parker
Software Creations               http://www.scbbs.com
Self-Administration Web Site     http://saw.scbbs.com
SDSS Subscription Mgmt Service   http://sdss.scbbs.com
Central Ave Dance Ensemble       http://www.centralavedance.com
R & B Salsa                      http://www.randbsalsa.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070828/1f3100ff/attachment-0001.htm