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