URL:
<http://savannah.gnu.org/bugs/?48930>
Summary: crash server crashes after --core-file-name is
changed with fsysopts
Project: The GNU Hurd
Submitted by: kon
Submitted on: Sun Aug 28 14:07:56 2016
Category: Hurd Servers
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Reproducibility: Intermittent
Size (loc): None
Planned Release: None
Effort: 0.00
Wiki-like text discussion box:
_______________________________________________________
Details:
% mkdir ~/servers
% settrans --create --active ~/servers/crash /hurd/crash
% fsysopts ~/servers/crash
/hurd/crash --action=suspend --orphan-action=core-file
% fsysopts ~/servers/crash --core-file-name=foo
% fsysopts ~/servers/crash
/hurd/crash --action=suspend --orphan-action=core-file --core-file-name=foo
% fsysopts ~/servers/crash --some-unsupported-long-option
fsysopts: /home/kalle/servers/crash: --some-unsupported-long-option: Invalid
argument
% fsysopts ~/servers/crash
fsysopts: /home/kalle/servers/crash: (ipc/mig) server died
Apparently, 'char *arg' passed to trans/crash.c (parse_opt) points into the
'options: data_t' buffer of the received fsys_set_options request. parse_opt
assigns this pointer to corefile_template, but the buffer can be reused or
freed after parse_opt returns.
Possible fixes:
(a) Prevent changing --core-file-name via fsysopts. This would be easiest to
implement by setting a flag after the argp_parse call in the main function and
then checking that flag in parse_opt. If --core-file-name is used after the
flag has been set, then return an error. Although perhaps it should allow
using --core-file-name with an argument that matches the current
corefile_template, so that any argument list retrieved from fsys_get_options
can be fed back to fsys_set_options without causing an error. In that case,
it should not change corefile_template.
(b) Always use strdup when setting corefile_template, and free the previous
string. Add locking so that it doesn't crash if different threads receive
fsys_set_options and crash_dump_task requests at the same time. It could be
an RW lock, although high contention seems unlikely.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?48930>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
