Bug 979225 - server.allow-insecure aka rpc-auth-allow-insecure option does not work
server.allow-insecure aka rpc-auth-allow-insecure option does not work
Status: CLOSED NOTABUG
Product: GlusterFS
Classification: Community
Component: glusterd (Show other bugs)
3.4.0-beta
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: krishnan parthasarathi
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-27 22:08 EDT by Louis Zuckerman
Modified: 2015-11-03 18:05 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-27 23:04:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Louis Zuckerman 2013-06-27 22:08:20 EDT
Description of problem:

I need to allow clients to connect to the volume from insecure (unprivileged) ports >1024.  There appears to be an option in 3.4 to do this: server.allow-insecure.  However when I set this to "ON" or "on" it has no effect, glusterd still refuses to serve clients on unprivileged ports.

Version-Release number of selected component (if applicable):

3.4.0beta3


I'll update this bug with steps to reproduce as soon as I have a good procedure for you.

Thanks!
Comment 1 Louis Zuckerman 2013-06-27 22:30:34 EDT
Shortly after I filed this bug Vijay chatted me on IRC to let me know that in addition to setting server.allow-insecure to on, I also needed to manually add an option to glusterd.vol:

    option rpc-auth-allow-insecure on

I restarted glusterd with the updated volfile and now I can use insecure ports.

Thanks again!
Comment 2 Louis Zuckerman 2013-06-27 22:51:33 EDT
Ok now I have a real bug to report....

After making the change above to glusterd.vol my insecure client program is able to communicate with glusterd to fetch the volfile, however....

When I try to create a file in the volume, nothing happens -- no error, no crash, no file created.

Then when I try to write data into that file, the process crashes and I get a core dump.

To reproduce this problem see the instructions in the readme.md file of the libgfapi-jni project:

https://github.com/semiosis/libgfapi-jni

Those instructions include a "sudo bash" command which will run the test as root.  But DO NOT run it as root to reproduce this problem.  The test succeeds when run as root, but fails when run as an unprivileged user.
Comment 3 Louis Zuckerman 2013-06-27 23:00:36 EDT
Ok I feel dumb.  The insecure client couldn't create or write to the file because the volume permissions didn't allow it.  Once i did a chmod ugo+rwx on the volume, it worked.

PEBKAC

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