privsep patch, Please test (take 2)

[Tim Rice]

On Thu, 30 May 2002, Ben Lindstrom wrote:

>
>
> 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.

I did that by design.

> 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.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

OK.  My test won't do that. I'll rewrite it.

> 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
>

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net