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.
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.
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).
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.
(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?
In the current releases, the default setting for glusterd is rpc-auth-allow-insecure off. So this shouldn't be an issue anymore.