[grsec] Restrictions on /proc/<pid>/[maps|stat] - relax for /proc/self?

[Dan Hollis]

On Tue, 11 Oct 2005, Kevin F. Quinn wrote:
> On 6/10/2005 15:09:58, Dan Hollis (reg5423374856 at anime.net) wrote:
>> On Thu, 6 Oct 2005, Kevin F. Quinn wrote:
>>> Generally speaking, the data in /proc/self/maps and /proc/self/stat
>>> isn't secret as such; an application knows where its code, data and
>>> stack are including the location of code in shared libraries.  However
>>> it's just easier and more reliable to grab the relevant information from
>>> /proc/self/maps and /proc/self/stat.
>> afaik this has never been the case. not only has the format changed in
>> the past, you can't even rely on /proc existing at all.
>> dl_iterate_phdr is the only 'reliable' method i know of. it also provides
>> somewhat more verbose data on mappings than /proc/(pid|self)/maps
>> does.
> Hmm; as far as I can tell, dl_iterate_phdr doesn't detail all the maps, it
> just returns Elf program header data.  So it's missing the stack base and
> size in particular (which is the reason why glibc and boehm-gc are parsing
> /proc/self/{maps|stat}).

proc/maps doesn't detail all the maps either, it's dependent on your 
kernel version and architecture. you can't depend on proc/maps having the 
information you want, let alone be present at all ...

you can depend on dl_iterate_phdr being there, but you can't depend on it 
having all the info you want :)

-Dan