Bug 51994 - Mod_authn_socache should have some way to flush the cache
Summary: Mod_authn_socache should have some way to flush the cache
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_authn_socache (show other bugs)
Version: 2.3.12-beta
Hardware: PC Linux
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2011-10-07 15:35 UTC by Jan Wolter
Modified: 2018-11-07 21:09 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Wolter 2011-10-07 15:35:20 UTC
I think the major defect with mod_authn_socache is that it lacks a way to flush the authentication cache. The timeout just isn't fully satisfactory. It means that it takes minutes before a password change actually takes effect, and a user can keep accessing resources for minutes after his account has been deleted.  If there were some mechanism by which a password change program or account deletion program could signal mod_authn_socache to flush it's cache, then not only would these actions take effect instantaneously, but administrators could freely set their timeout values higher, improving performance on all authentications.

Either a mechanism that empties the entire cache or one that just de-caches a single user would be fine.

I think the easiest way to do this would be to have a special password that flushes the cache. So, if a user makes a request with the special password, say 'AllOthersPayCache' then (1) mod_authn_socache would erase it's cache entry for the user, and (2) mod_authn_socache pass on the authentication, just as it would if the user wasn't in cache. So even if some ridiculous user chose that as their password, the site would still work for them, though without caching.

Site administrators would have to train their user deletion and password change programs to hit the website with a request with the username and special password, but that's not hard.

Lots of other mechanisms could be used, and probably one can think of some that are more graceful than this one (though probably not one that's easier to implement) but I really think you would double the practical value of the module if some such mechanism were available.
Comment 1 Nick Kew 2011-10-07 16:10:35 UTC
This is documented behaviour!

Does a server restart (or 'graceful') fix it?  That might depend on what socache backend you're using.
Comment 2 Jan Wolter 2011-10-07 18:19:15 UTC
Yes, it's documented, so this an enhancement request, not a bug request.

Without a cache flush you put administrators into the tricky position of having to decide between long timeouts for performance and short timeouts so password changes and account deletions happen smoothly. That dilemma is a false one, arising out of an weakness in the software design. Good caches are flushable.

Yeah, server restart probably works for some back-ends, at least. Kind of extreme. If they are using a dbd file it might not be hard to write a separate program that erases it. With more work, they could probably even do that with shared memory. But if that's the way to go, then do we expect every administrator to write their own? They might be able to do something with setting the cache timeout temporarily to zero, hitting the page with the user ID and a random bad password, and setting it back again. No,that won't work - looks like changing the timeout won't effect the timeout of things already in the cache. I can't say any of these solutions are elegant.

I don't know. I think this is going to be a common enough concern with users of mod_authn_socache that a reasonably clean and graceful way of handling it ought to be part of the design. It's worth at least making the attempt to come up with a smart solution to the problem.

Maybe it'd be good enough to have authn_cache_store() modified so that if you pass it a NULL for the data argument it removes that user from the cache. Then third-party modules could be written that do cache flushes. The scheme I described in my original post could totally be a separate module, listed before socache on the AuthBasicProvider directive, if only it had a way to ask mod_authn_socache to flush a cache entry.
Comment 3 William A. Rowe Jr. 2018-11-07 21:09:54 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.