sevenmine / mod-authn-otp

Automatically exported from code.google.com/p/mod-authn-otp
Apache License 2.0
0 stars 0 forks source link

problem with concurent access to sec file. (file.sec.new no such file.) #22

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
We have a apache server that authenticate using OPT, we notice that within more 
than a couple of connection per second the user in the security file are 
deleted.

We got some error in Apache log : 

[Thu May 09 08:13:59 2013] [error] [client 000.000.000.000] error renaming new 
OTP users file "/%%path_to_file%%/conf/%%file%%.sec.new" to 
"/%%path_to_file%%/conf/%%file%%.sec": No such file or directory

I masked %%path_to_file%% and %%file%%, 

We notice that the problem is more visible when the same user is using two 
device at the same time, so we have remove logout on ip change, (we waiting for 
result), but it is not a permanent solution. 

-----------------------------------------
What version of the module are you using?   1.1.6

On what operating system?  I'm the one using it on solaris :-)

         AuthName "???"
         AuthType Basic
         AuthBasicProvider OTP
         Require valid-user
         OTPAuthUsersFile       /%%PATH_TO_FILE%%/%%FILE%%.sec
         OTPAuthLogoutOnIPChange On
         OTPAuthMaxLinger 600
         OTPAuthMaxOffset 4

Original issue reported on code.google.com by m...@mconcept.ca on 9 May 2013 at 1:46

GoogleCodeExporter commented 9 years ago
This problem is very likely to be Solaris-specific, as no one else has 
complained about it since the first release.

Exclusive locking in mod-authn-otp is done on line 190 of mod_authn_otp.c:

 181     /* If updating, open and lock lockfile */
 182     if (update) {
 183         apr_snprintf(lockusersfile, sizeof(lockusersfile), "%s%s", usersfile, LOCKFILE_SUFFIX);
 184         if ((status = apr_file_open(&lockfile, lockusersfile,
 185           APR_WRITE|APR_CREATE|APR_TRUNCATE, APR_UREAD|APR_UWRITE, r->pool)) != 0) {
 186             ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, "can't open OTP users lock file \"%s\": %s",
 187               lockusersfile, apr_strerror(status, errbuf, sizeof(errbuf)));
 188             goto fail;
 189         }
 190         if ((status = apr_file_lock(lockfile, APR_FLOCK_EXCLUSIVE)) != 0) {
 191             ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, "can't lock OTP users lock file \"%s\": %s",
 192               lockusersfile, apr_strerror(status, errbuf, sizeof(errbuf)));
 193             goto fail;
 194         }
 195     }

There may be some bug or problem in the Solaris implementation of 
apr_file_lock().

Are you capable of doing some debugging? If so try adding some logging to that 
function that logs each time the lockfile is locked and unlocked and then see 
if there is evidence that apr_file_lock() is not actually serving as an 
exclusive lock.

Original comment by archie.c...@gmail.com on 9 May 2013 at 3:08

GoogleCodeExporter commented 9 years ago
This does not seem to be Solaris specific, it happens where with version 1.1.6
on CentOS release 6.4 (Final)

Original comment by heribert...@googlemail.com on 22 Apr 2014 at 8:45

GoogleCodeExporter commented 9 years ago
Which Apache MPM modules are you guys using? E.g., prefork, worker, event.

See http://httpd.apache.org/docs/2.4/mod/#core for a list.

I'm wondering if this problem only occurs when not using prefork...?

Original comment by archie.c...@gmail.com on 28 Apr 2014 at 9:15

GoogleCodeExporter commented 9 years ago
I'm pretty sure this was the problem. Should be fixed in r146 and will appear 
in release version 1.1.8.

Please do a custom build with the current SVN head including 
http://code.google.com/p/mod-authn-otp/source/detail?r=146 and let me know if 
this fixes the problem.

Thanks.

Original comment by archie.c...@gmail.com on 28 Apr 2014 at 10:00

GoogleCodeExporter commented 9 years ago
Have either of you been able to test out the fixes to this bug in r146?

I'd like to confirm the problem is fixed before releasing it.

Thanks.

Original comment by archie.c...@gmail.com on 13 May 2014 at 7:50