This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 765359 - (GLUSTER-3627) Local user's can abuse gluster
Local user's can abuse gluster
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: glusterd (Show other bugs)
3.2.3
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Kaushal
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-25 03:03 EDT by David
Modified: 2015-12-01 11:45 EST (History)
6 users (show)

See Also:
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:


Attachments (Terms of Use)

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.