Hide Forgot
Also observed on my setup: When a subvolume is configured to be authenticated via addr & login modules, 1. if only addr matches and login details fail to match - Authentication succeeds. 2. if addr does not match and login details match - Authentication fails. Effectively, it is addr only authentication when both login & addr are both specified. -- Gowda
[Migrated from savannah BTS] - bug 25252 [https://savannah.nongnu.org/bugs/?25252] Mon 05 Jan 2009 09:39:05 AM GMT, original submission by Swankier: first match wins. -------------------------------------------------------------------------------- Mon 05 Jan 2009 02:38:40 PM GMT, comment #1 by Raghavendra <raghavendra>: Can you please explain the problem more descriptively? Both the modules can be used in conjunction to get both login and address based communication. regards, Raghavendra -------------------------------------------------------------------------------- Mon 05 Jan 2009 04:27:43 PM GMT, comment #3 by Swankier: The first one listed in the config will match, the second will be ignored. This was reported by a user on irc. I do not have example configs. -------------------------------------------------------------------------------- Mon 05 Jan 2009 02:39:55 PM GMT, comment #2 by Raghavendra <raghavendra>: Sorry for the typo. I meant "both login and address based authentication".
raghu can you confirm the previous observation and take care of fixing it? I think its not priority but surely nice to have the bug fixed sometime.
this is very much required used by one of the customers "EnvoyMedia", but it seems working for him as he is using 2.0.8
Need verification
server vol file : option auth.addr.brick1.allow 192.168.101.21 option auth.login.brick1.allow laks option auth.login.laks.password pwd If there is a mismatch in username , but password matches - (returns AUTH_DONT_CARE) it passes authentication. client vol file: option username laks1 option password pwd If username matches , but password mismatches- (returns AUTH_REJECT) authentication fails. client vol file: option username laks option password pwd4
The behaviour observed below is correct. The authentication policy is "none of the authentication modules should reject and atleast one of them should accept". Since we are passing an username, auth-login is checking for corresponding password. (In reply to comment #5) > server vol file : > option auth.addr.brick1.allow 192.168.101.21 > option auth.login.brick1.allow laks > option auth.login.laks.password pwd > > If there is a mismatch in username , but password matches - (returns > AUTH_DONT_CARE) it passes authentication. > > client vol file: > option username laks1 > option password pwd > > > If username matches , but password mismatches- (returns AUTH_REJECT) > authentication fails. > > client vol file: > option username laks > option password pwd4
If the reason for this bug still being open is observation made by Lakshmipathi, Can we close the bug, since authentication is behaving as per the intended policy? regards, Raghavendra
server started with-out option auth.addr server vol file : option auth.login.brick1.allow laks option auth.login.laks.password pwd If there is a mismatch in username , but password matches - authentication fails. client vol file: option username laks1 option password pwd If username matches , but password mismatches- authentication fails. client vol file: option username laks option password pwd4 It works as expected.
Lakshmipathi has confirmed that authentication works as expected. Hence I am closing this bug.