privsep patch, Please test (take 2)

[Ben Lindstrom]

On Thu, 30 May 2002, Tim Rice wrote:

> On Thu, 30 May 2002, Ben Lindstrom wrote:
>
> >
> >
> > Ermm.. I think your configure.ac is invalid.
> >
> > Two things.
> >
> > 1. Lack of MAP_ANON/MAP_ANONYMOUS does not mean mmap is broken.  Just
> > means it lacks a useful feature.
>
> True. Look again. the test doesn't fail on lack on MAP_ANON
>
> >
> > 2. Linux 2.2 has a MAP_ANON but it's broken.  But that is a seperate issue
> > from the fact that MAP_SHARED seems also to be broken.  I think they need
> > to be tested seperately.
> >
> > Because if MAP_ANON is not useful (does not exist) we have a fallback
> > plan.  However if MAP_SHARED is broken.  We are SOL.
>
> Do we want to someone on a 2.2 kernel to be able to enable privsep
> and then have it fail if the client requests compression?
>
> With MAP_PRIVATE, on linux 2.2 it will work until  you use compression.
>
#include <stdio.h>
#include <sys/mman.h>
#if !defined(MAP_ANON) && defined(MAP_ANONYMOUS)
#	define MAP_ANON MAP_ANONYMOUS
#endif

main()
{
	void *address;
#ifdef MAP_ANON
	address = mmap(NULL, 10, PROT_WRITE|PROT_READ, MAP_ANON|MAP_SHARED, -1, 0);
	if (address == MAP_FAILED)
		exit(1);
#endif
	exit(0);
}


Problem with this. Is it gives a fault positive.  if MAP_ANON does not
exist exists happily as if it does.  No way to tell the difference between
no MAP_ANON and good MAP_ANON.

Second issue is the 2.2 issue.  The above fails.  And we short cut out.
Do we know for a fact that other platforms with MAP_ANON that are invalid
or broken may still have usable MAP_SHARED?

You are combining two tests into one.  They should be two seperate tests.


1. Test for a usable MAP_ANON.
2. Test for usable open(/dev/zero)/MAP_SHARED test.

For a few reasons.  PrivSep does not required mmap to do 90% of its job.
Just requires it for compression.  And it would be nice if we could
support PrivSep without compression.

Which means we add a line to end of configure.ac with the following:

Priv Seperation:  {Fully enabled, No compression Support, Broken}

Why?  Because in the next full release Theo is going to expect us to have
PrivSep on by default.  And I'd at least like to let people see what level
of PrivSep they can expect so they can disable it if it will not suite
their needs.

At this point if we could just get the code in to handle things cleanly
without disabling compression support.  It would make things easier when
we go back and add it.

- Ben