Re: [Handle-info] Admin groups, HS_VLIST and the handle admin tool: caching issues?

[Scott Prater <sprater@doit.wisc.edu>]

Thanks, Sean.  I'll keep your advice in mind when managing groups.  For what it's worth, I did send an authoritative query to the handle server for 9999/AdminGroup immediately after deleting the handle, to no effect;  does an authoritative query flush the client cache, but not the server cache?

-- Scott

----- Original Message -----
From: Sean Reilly <sreilly@cnri.reston.va.us>
Date: Monday, April 14, 2008 11:32 am
Subject: Re: [Handle-info] Admin groups, HS_VLIST and the handle admin tool:  caching issues?
To: Scott Prater <sprater@doit.wisc.edu>
Cc: handle-info@cnri.reston.va.us


> On Apr 9, 2008, at 18:06 , Scott Prater wrote:
> > While doing some testing, I ran into some odd behavior:  I found I  
> 
> > still had permission to modify a handle and its values in the handle 
>  
> > admin tool even after the handle for the admin group to which I  
> > belonged was deleted.
> >
> > Here are the steps to duplicate the behavior.  I changed my test  
> > naming authority to 9999 below to protect the innocent.
> >
> > 1.  Start handle admin tool, authenticate as 0.NA/9999 admin.
> >
> > 2.  Create a new handle for authentication:
> >
> >    9999/ScottAuth
> >        100:  HS_ADMIN          0.NA/9999:300
> >        300:  HS_PUBKEY	Public key for Scott
> >
> > 3.  Create a new group authorization handle:
> >
> >    9999/AdminGroup
> >        100:  HS_ADMIN  0.NA/9999:300
> >        200:  HS_VLIST  9999/ScottAuth:300
> >
> > 4.  Create a test handle, with permissions to modify given to  
> > AdminGroup:
> >
> >    9999/TestHandle
> >        100:  HS_ADMIN  0.NA/9999:300
> >        101:  HS_ADMIN  9999/AdminGroup:200 (ttl:86400)
> >        500:  URL	http://www.nytimes.com/ (ttl: 86400)
> >
> > 5.  Exit the handle tool, start it up again, authenticate with 9999/ 
> 
> > ScottAuth, and modify the URL value for 9999/TestHandle,
> >
> > Up to this point, everything works as expected.  You can modify the  
> 
> > handle, once you're authenticated.
> >
> > 6.  Exit the admin tool, start it up again, authenticate as 0.NA/ 
> > 9999, and delete the handle 9999/AdminGroup.
> >
> > 7.  Query the handle 9999/AdminGroup, checking "Authoritative".  As  
> 
> > expected, I get a "HANDLE NOT FOUND" error.
> >
> > 8.  Exit the handle tool, start it up again, authenticate with 9999/ 
> 
> > ScottAuth, and modify the URL value for 9999/TestHandle.
> >
> > Even though the 9999/AdminGroup handle no longer exists, its values  
> 
> > are cached, and you can modify the handle.  Is this correct behavior?
> 
> Yes, this is correct behavior because the 9999/AdminGroup handle is  
> cached by the handle server.
> 
> > To refresh permissions for 9999/TestHandle, I tried setting TTL  
> > value to 0 on both the 500:URL and 101:HS_ADMIN handle values with  
> 
> > no luck:  I was still able to modify the handle, even after closing  
> 
> > the handle admin tool, restarting it, and reauthenticating.
> >  I also tried to refresh permissions by querying the 9999/TestHandle 
>  
> > with the "Authoritative" box checked in the handle admin tool, with  
> 
> > no luck:  I was still able to modify the handle.  Finally, the only  
> 
> > way I could remove my authorization was by deleting the 101:HS_ADMIN 
>  
> > value from 9999/TestHandle.
> >
> > It seems like HS_VLIST authorization information is getting cached  
> 
> > somewhere and not refreshed.  Can others reproduce this problem, if  
> 
> > it is indeed a problem?  Am I missing something?
> 
> 
> Right.  This is because 9999/AdminGroup is being cached by the handle  
> 
> server.  You might be able to flush that handle from the cache by  
> sending an authoritative request for it to your handle server,  
> although it would be much better if you modified 9999/AdminGroup  
> instead of deleted it.  You could also set the TTL for 9999/AdminGroup 
>  
> values to a lower number, but it would have to have been done before  
> 
> the value with the old TTL was cached, or after it expired.
> 
> If the server had to re-resolve all of the admin/group handles for  
> every handle operation then administration would take an unbearably  
> long time :)
> 
> Thanks,
> Sean
> 
> 


_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info