Bug 765359 (GLUSTER-3627)

Summary: Local user's can abuse gluster
Product: [Community] GlusterFS Reporter: David <db.pub.mail+gluster>
Component: glusterdAssignee: Kaushal <kaushal>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: low    
Version: 3.2.3CC: aavati, amarts, gluster-bugs, jdarcy, kdhananj, kparthas
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-20 02:07:31 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description David 2011-09-25 03:03:39 EDT
Ok so I understand that gluster has a few limited authentication mechanisms and that there is a more secure back-end in the works but for now there is only ip/host based auth.

This bug is concerned with the gluster (cli) operation on the host itself. While the cli.c source file usually will only run as root, I patched it (in two places - the first initial geteuid check and the location of the log file(if I was a non-root user)) so that it would run as any user. Then I just fired up a gluster prompt like this:
--------
root@mybox #su nobody
$ bash
nobody@mybox:/tmp$ gluster
volume info
     Volume Name: SIF
     Type: Distribute
     Status: Started
     Number of Bricks: 1
     Transport-type: tcp
     Bricks:
     Brick1: 10.0.22.183:/tmp

gluster> volume log filename SIF  /etc/passwd3
     log filename : successful

--------
Then I checked to see if /etc/passwd3 was created, it was indeed.
(basically any local user who recompiled gluster can play with it - which is probably what one might expected). I consider this to be a security issue because even in file-systems like NFS, local (non-root) users are _not_ (normally) allowed to do this.
Comment 1 Amar Tumballi 2011-09-26 00:01:31 EDT
Its a good idea to remove the feature of giving a 'filename' for the log filename option (which is changed already in master), instead only allow directories in which we can create the log files.
Comment 2 David 2011-09-26 02:08:13 EDT
Actually, that's not the issue here. Perhaps I wasn't clear enough. The title of the bug is "Local user's can abuse gluster" and I gave an example of abusing one of the many gluster CLI commands (as the nobody user). The actual issue here is that "Local user's can abuse gluster" (non-root users) ... and they really shouldn't be able to abuse it :p
Remember _any_ local user can delete _any_ gluster volume available (from what I can tell) (and create a new one).
Comment 3 Amar Tumballi 2011-09-26 02:14:33 EDT
That can be solved by having an option in 'glusterd.vol',  'option rpc-auth-allow-insecure off'. That way, glusterd doesn't allow any connection from user programs. Please check if that is enough.
Comment 4 David 2011-09-26 02:32:29 EDT
(In reply to comment #3)
> That can be solved by having an option in 'glusterd.vol',  'option
> rpc-auth-allow-insecure off'. That way, glusterd doesn't allow any connection
> from user programs. Please check if that is enough.

It seem to fix the (patched) cli access from the nobody user.
Why isn't that setting 'off' by default?
Comment 5 Kaushal 2013-06-20 02:07:31 EDT
In the current releases, the default setting for glusterd is rpc-auth-allow-insecure off. So this shouldn't be an issue anymore.