Bug 761774 (GLUSTER-42)

Summary: auth.login and auth.addr cannot be used in conjunction with each other
Product: [Community] GlusterFS Reporter: Basavanagowda Kanur <gowda>
Component: protocolAssignee: Lakshmipathi G <lakshmipathi>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: mainlineCC: amarts, fharshav, gluster-bugs, pavan, raghavendra, vijay
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: RTA Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Basavanagowda Kanur 2009-06-23 16:51:23 UTC
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

Comment 1 Basavanagowda Kanur 2009-06-23 19:48:32 UTC
[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".

Comment 2 Amar Tumballi 2009-11-26 03:15:36 UTC
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.

Comment 3 Harshavardhana 2009-11-26 04:11:16 UTC
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

Comment 4 Pavan Vilas Sondur 2010-01-19 08:29:46 UTC
Need verification

Comment 5 Lakshmipathi G 2010-03-30 07:02:37 UTC
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

Comment 6 Raghavendra G 2010-04-27 10:09:10 UTC
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

Comment 7 Raghavendra G 2010-04-27 11:09:28 UTC
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

Comment 8 Lakshmipathi G 2010-04-28 03:06:48 UTC
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.

Comment 9 Raghavendra G 2010-04-28 03:08:21 UTC
Lakshmipathi has confirmed that authentication works as expected. Hence I am closing this bug.