[development] Changing Roles (was Deleting Cached Permissions)

David Metzler metzlerd at metzlerd.com
Tue Aug 28 14:21:30 UTC 2007


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

>
> 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

Karoly, thanks for bringing up some options for a solution.  This  
might work with the new menu system, provided we have a way to  
override other modules menus access control.  Is that what you're  
suggesting? But what Ron is trying to do is override permissions for  
other modules, (book, page,etc.).  That means that Ron needs a way to  
overdefine all of the menu items for node/*/add.  Will that work, or  
does the uniquely defined menu item supercede the other.

Would overriding these menu items be thought of as a "supported way"  
of writing a module?

If you're suggesting duplicating all of the modules menu code in the  
organic groups module, I don't see how mucking with the other peoples  
menu structures on other modules is fundamentally cleaner than  
elevating a role.  There's a lot more opportunity for funky  
behavior.  Then there's the problem that menu items are also cached.   
So we run into similar prolbems there yes?

>
> 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.

Aren't all of these issues still there if you fiddle with menu access  
control on the fly?  If not, why is it different?

Ron isn't asking for a way to escalate privileges that isn't  
supported.  Ron is asking for control about whether drupal caches  
those permissions.  As I've said, this has implications for any  
module that wants to alter a users role, whether it does so  
temporarily or on login.  I've fought similar bugs in my cas module,  
but I can see problems here with LDAP Groups and other modules that  
want to alter a users role programmatically.

I think it's odd to say we don't want to support a mechanism because  
we're worried it will be called to often. It's only the frequency of  
the call that seems to be in debate here.  (I don't want users to be  
able to change roles on every page load).

>
> Regards,
>
> NK



More information about the development mailing list