Bugzilla – Bug 6698
grid-mapfile lines longer that 1022 (1024-2) characters cause segfault
Last modified: 2010-02-24 05:53:45
You need to
before you can comment on or make changes to this bug.
Here's the stack backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208183104 (LWP 5456)]
0x00d7c055 in globus_i_gss_assist_gridmap_find_local_user (local_user=0xa0e3dd0
"vwelch", gline=0xbfe7e338) at gridmap.c:726
726 for(useridp = gline_tmp->user_ids;
#0 0x00d7c055 in globus_i_gss_assist_gridmap_find_local_user
(local_user=0xa0e3dd0 "vwelch", gline=0xbfe7e338) at gridmap.c:726
#1 0x00d7b920 in globus_gss_assist_map_local_user (local_user=0xa0e3dd0
"vwelch", globusidp=0xbfe7e36c) at gridmap.c:419
The globus_gss_assist_map_local_user() function calls fgets() with a 1024
character buffer but does not check whether the line has been truncated by
looking for '\n' at the end of the string. So, lines longer than 1022
characters (1024-2 for the '\n' and '\0' terminating characters) will be split
and processed as multiple lines, causing parse errors that result in
segmentation faults (see Bug 6429). This was also noted in Bug 4180. This bug
was crashing NCSA's production myproxy-server today until we removed the
offending grid-mapfile line from NCSA's grid-mapfiles.
I see 3 calls to fgets() in gridmap.c that behave this way.
At minimum, these functions should throw an error on too-long lines and/or
discard them (completely) and keep processing, but ideally they'd use a
dynamically-sized buffer to handle lines of any length in the grid-mapfile.
Initial patch (committed to bug_6698_branch) is available from
This patch is from the gsi/gss_assist directory and contains an update to the
parser and a new test case for long gridmap file lines.
Do you have any feedback on this?
(In reply to comment #2)
> Do you have any feedback on this?
Patch looks good to me. Thanks.
This fix is committed to 4.2 and 5.0 branches and the trunk.