shm: Respect PROT_MAX when creating private mappings

We were previously unconditionally adding PROT_WRITE to the maxprot of
private mapping (because a private mapping can be written even if the
fd i

shm: Respect PROT_MAX when creating private mappings

We were previously unconditionally adding PROT_WRITE to the maxprot of
private mapping (because a private mapping can be written even if the
fd is read-only), but this might violate the user's PROT_MAX request.

While here, rename cap_maxprot to max_maxprot. This is the intersection
of the maximum protections imposed by capsicum rights on the fd (not
really relevant for private mappings) and the user-required maximum
protections (which were not being obeyed). In particular, cap_maxprot
is a misnomer after the introduction of PROT_MAX.

Add some regression test cases. mmap__maxprot_shm fails without this
patch.

Note: Capsicum's CAP_MMAP_W is a bit ambiguous. Should it be required
in order to create writeable private mappings? Currently it is, even
though such mappings don't permit writes to the object referenced by the
fd.

Reported by: brooks
Reviewed by: brooks
MFC after: 1 month
Fixes: c7841c6b8e41 ("Relax restrictions on private mappings of POSIX shm objects.")
Differential Revision: https://reviews.freebsd.org/D46741

show more ...

Remove residual blank line at start of Makefile

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix