Bug#573571: Potential fix for cwd bug
Jesse Smith
jsmith at resonatingmedia.com
Tue Dec 18 14:54:05 GMT 2018
On 12/18/18 9:18 AM, Dmitry Bogatov wrote:
> [2018-12-16 12:35] Jesse Smith <jsmith at resonatingmedia.com>
>> I did some poking around and believe I've found the issue with isserv
>> jumping out whenever the current working directory (cwd) is not accessible.
>>
>> Basically, in the pushd() function there are two checks - one to see if
>> we can save the cwd, and another check to see if we can change to
>> /etc/init.d. If either of these checks failed, insserv would bail out.
>> The only important check is the second one (moving to /etc/init.d), but
>> both were treated as the same, fatal error and resulted in the same
>> error message being printed.
>>
>> The attached patch fixes this situation so the two errors are handled
>> separately. The first check (saving cwd) will fail gracefully with an
>> error to stderr. The second check, moving to /etc/init.d, will fail with
>> a fatal error.
>>
>> This patch also addresses some potential segfault issues in popd().
>> These probably would not happen in any practical environment, but the
>> extra checks should avoid crashes in the future if a directory gets
>> removed while insserv is running.
>>
>> This fix will appear in upstream version 1.19.0 in the new year. This
>> patch should address the issue in 1.18.0 and earlier releases.
>> diff --git a/Makefile b/Makefile
>> index cf84e66..5556965 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -76,7 +76,7 @@ endif
>> TODO = insserv insserv.8
>>
>> all: $(TODO)
>> - ln -s ../insserv tests/insserv
>> + $(LINK) ../insserv tests/insserv
> Improvements of style in Makefile are not strictly part of
> resolution of this issue, aren't they?
The edit to the Makefile is not really related to this issue. Though it
is a good idea to have the change in place to avoid compile-time errors.
>
>> diff --git a/insserv.c b/insserv.c
>> index e109341..4df4cdc 100644
>> --- a/insserv.c
>> +++ b/insserv.c
>> [...]
> I am not familiar with code, but why insserv need to save current
> directory in first place? But otherwise patch works for me.
I haven't dug into it, to be honest. I know there are a handful of
places in the code where insserv jumps to different directories and then
traces back, but I haven't looked into why it needs the trail of
breadcrumbs.
> Any chance to something like insserv-1.18.1 release?
Probably not, at least not in the next six weeks.
More information about the Debian-init-diversity
mailing list