Re: Security question: "Text file busy" overwriting executables but not shared libraries?

Eric W. Biederman
2001-10-04T06:25:04Z

Alexander Viro <viro@math.psu.edu> writes:

> On 3 Oct 2001, Eric W. Biederman quoted:
>
> > > >/* The right way to map in the shared library files is MAP_COPY, which
> > > > makes a virtual copy of the data at the time of the mmap call; this
> > > > guarantees the mapped pages will be consistent even if the file is
> > > > overwritten. Some losing VM systems like Linux's lack MAP_COPY. All we
>
> > > > get is MAP_PRIVATE, which copies each page when it is modified; this
> > > > means if the file is overwritten, we may at some point get some pages
> > > > from the new version after starting with pages from the old version. */
>
>
> IMO it needs a slight correction.
>
> + /* Unfortunately, that is not an option, since losing bloatware like GNU's
> + relies heavily on equally bloated shared libraries and use of MAP_COPY
> + would eat memory with no mercy. OTOH, implementing it might be a good
> + idea, since results would force people to switch to something less obese */

Hmm. Perhaps. But if we went there we would need to add something like.

/* But finding a less obese platform to run these less obese libraries is a
challenge. Unix clones like UZI have been shown to run a complete system
including user space binaries in just 64KB of RAM, on systems
originally designed to run CPM. But today you can't find a general
purpose kernel whose binary much less it footprint fits in 256KB.
It seems bloatware is everywhere.
*/

I have days when I'm frustrated by the size of both glibc and the
linux kernel. stripped both the linux kernel and glibc are comparable
in size. Though I think the 400KB of compressed glibc-2.1.2 is
actually smaller than the kernel for the most part. I have to strip
off practically everthing to get a useable bzImage under 400KB.

So any good ideas on how to get the size of linux down?

Eric