On 1/25/06, Nix <[email protected]> wrote:
> On 23 Jan 2006, Albert Cahalan said:
> > On 1/23/06, Arjan van de Ven <[email protected]> wrote:
> >> On Mon, 2006-01-23 at 04:28 -0500, Albert Cahalan wrote:
> >
> >> > I tend to think that glibc should not be reading this file.
> >> > What excuse is there?
> >>
> >> glibc needs to be able to find out if a certain address is writable. (eg
> >> mapped "w"). The only way available for that is... reading the maps
> >> file.
> >
> > What the heck for? That's gross.
>
> Ironically enough, it's security. :)
>
> > If glibc is just providing this info for apps, there should be a
> > system call for it. Otherwise, being the C library, glibc can
> > damn well remember what it did.
>
> Nah, it's used for vfprintf() argument-area checking.
>
> Specifically, it's the Linux implementation of __readonly_area(),
> located in sysdeps/unix/sysv/linux/readonly-area.c in glibc-3.4-to-be,
> and used by vfprintf() on behalf of __vfprintf_chk(). Calls to this
> function (and the other __*_chk() functions) are expanded by glibc's
> string headers and generated by GCC 4.1+ automatically when possible
> (and by GCCs out there in the field: this patch is shipped by RH
> already, known as FORTIFY_SOURCE).
>
> FORTIFY_SOURCE zaps a whole class of security vulnerabilities stone
> dead. Breaking it would be a bad idea. Therefore, /proc/self/maps has to
> remain readable, even in setuid programs, because setuid programs are
> one class of programs for which FORTIFY_SOURCE is crucial.
>
> [Jakub added to Cc:, he can defend his own code much better than I can]
OK, Jakub, how would you like the system call to look? :-)
It looks like the mincore() system call has reserved bits
available in the output vector.
It's just vfprintf? Not vsprintf too? I'll take a guess that the
performance hit was considered tolerable only if doing IO
anyway. A proper system call would help both cases.
It's bad enough that procps has to suffer the overhead of
parsing all that nasty text. The thought of every app doing
that, automatically via gcc+glibc, is truly horrifying.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
