Richard suggests:
> Perhaps a simpler task would be to "set" all HFS programs have
> *selected* capabilities, like MR, LG, etc. that aren't really
> security risks.

The only capabilities that apply to GROUPs are the ones that apply to
PROGRAMs, and thus are the ones which we have a potential need for with HFS
directories:

IA - Interactive Access
BA - Batch Access
PH - Process Handling
PM - Privileged Mode
MR - Multiple Rins
DS - use extra Data Segments.

HFS directories currently behave as though they have IA and BA capabilities,
and sort of PH capability.

A program with PH capability running from an HFS directory checks the
program's PH capability against not the 'directory' capabilities (as happens
in an MPE GROUP) but with the USER's capabilities.  Thus PH capability in an
HFS directory requires that the USER running the program have PH capability,
and most users of Posix programs will thus require PH, otherwise you get an
annoying error which can take a while to figure out.

DS capability is pretty much obsolete, and it would be, I believe, 100% safe
to make HFS directories behave as though they had DS capability as well as
IA and BA.

That leaves us with PM and MR.  PM obviously needs to be controlled, but
you're probably right that MR really does not matter any more from a
security point of view.  We don't want all programs to behave as though they
*have* MR, since it changes the behavior of, and makes more dangerous,
programs that do file and database locking.  But as long as the system
respects whether the program file has MR or not, I'd vote for "giving away
MR for free" to all HFS directories.

PM is a trickier issue.

G.