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

[ebiederm@xmission.com (Eric W. Biederman)]

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