Bug 1269203
Summary: | regression : RHGS 3.0 introduced a maximum value length in the info files | ||||||
---|---|---|---|---|---|---|---|
Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | Cedric Buissart <cbuissar> | ||||
Component: | core | Assignee: | Gaurav Kumar Garg <ggarg> | ||||
Status: | CLOSED ERRATA | QA Contact: | Byreddy <bsrirama> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | rhgs-3.1 | CC: | amukherj, bkunal, bmohanra, bsrirama, byarlaga, rhs-bugs, sankarshan, smohan, storage-qa-internal | ||||
Target Milestone: | --- | Keywords: | ZStream | ||||
Target Release: | RHGS 3.1.2 | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | glusterfs-3.7.5-0.3 | Doc Type: | Bug Fix | ||||
Doc Text: |
Previously, if the user set an option where the length of key=value goes beyond PATH_MAX (4096) character then tokenzing the option at the time of reading configuration file will fail. Due to this, when the user tries to restart glusterd, after setting key=value length beyond PATH_MAX (4096) character, glusterd will not restart. With this fix, setting an option where key=value length can go beyond PATH_MAX is allowed.
|
Story Points: | --- | ||||
Clone Of: | |||||||
: | 1271150 1319670 (view as bug list) | Environment: | |||||
Last Closed: | 2016-03-01 05:37:32 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1260783 | ||||||
Attachments: |
|
Description
Cedric Buissart
2015-10-06 15:42:05 UTC
Created attachment 1080305 [details]
logs
Just to clarify : the issue is that fgets will not place the stream pointer to the next line. And next token read will fail because we will read the end of the line, and there will not be any '=' to parse - I dont think that PATH_MAX is an actual limitation, since the str seems to be allocated with the size of the whole file anyways Thus, should we loop on fgets, appending to str, until we reach the end of line/file ? - should the PATH_MAX be used here? since it's originally supposed to be a limitation in path length (i.e. : not line length) - The functions all seem to handle errors passing (gf_store_op_errno_t), but there does not seem to be a use of it. Maybe using it would help to clarify an unexpected result ? This looks like a definite regression. If we revert the code use fscanf things work fine. I do feel the culprit here is PATH_MAX since it limits fgets to read at max that many number of characters. If we end up having a key=value crossing PATH_MAX then this API will fail. Hi Atin, Thanks for looking into it! My fear was that this "PATH_MAX" was introduced on purpose and might have been a real limitation. However, if not, then we could use the file size as limitation, which I think is what is used for the string's allocation. (In reply to Cedric Buissart from comment #6) > Hi Atin, > Thanks for looking into it! > My fear was that this "PATH_MAX" was introduced on purpose and might have > been a real limitation. > > However, if not, then we could use the file size as limitation, which I > think is what is used for the string's allocation. That's right Cedric. This is exactly what the patch will look like. Gaurav will be sending a patch for this. upstream patch available: http://review.gluster.org/#/c/12346/ Verified this bug with the version 3.1.2 (glusterfs-3.7.5-0.3). Glusterd restart worked after setting key/value > 4096. Steps: (Same as reproducing steps specified above ) 1. Created a Distributed volume 2. Set the auth.allow with 4098 character length 3. glusterd restart worked fine. Based one above info. moving this bug to verified state. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0193.html |