Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 9 Sep 2013 11:49:12 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Third draft of musl documentation/manual

On Mon, Sep 09, 2013 at 02:09:46PM +0200, Bortis Kevin wrote:
> What happens if /etc/ld-musl-$(ARCH).path is:
>   * present, but not readable?
>   * present, but corrupt?
> 
> Does it always fallback to the default "/lib:/usr/local/lib:/usr/lib"?

The present behavior is that it falls back on any failure to open the
file, but if the file is opened and reading subsequently fails, no
fallback is used.

The intent was to avoid situations where resource-exhaustion attacks
could cause the wrong path to be used. I suspect all fopen failures
except ENOENT (e.g. ENFILE, EMFILE, ...) should also suppress the
fallback.

> The manual text does not describe these cases.

"Present but not readable" should probably be documented and have a
defined behavior. "Present but corrupt" is hard to define. In a sense,
any file content is "valid" except possibly embedded null bytes, but
most will not result in meaningful path searches. I'm doubtful that
it's useful to document or promise any reasonable behavior when the
file contains junk.

Thanks for the comments.

Rich
x

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.