"Johnson, Tracy" wrote:
> That leaves PM, I presume that by preventing HFS use of PM that
> is a big security FEATURE, otherwise POSIX code in HFS
> subdirectories could run GOD or GOD-like (I presume some
> can already but that's beside the point) programs.
>
> Allowing it seems to me like a big security HOLE.  HFS
> subdirectories don't have the same ACCESS= matrix that MPE groups
> do.  I.e., R,W,A,L,X,S + ANY, AC, GU, AL, GL.  The HFS
> subdirectory security matrix is only thus:  drwxrwxrwx [with
> each rwx trigraph similar to (I think) SM AM, and GU in descending
> order.]  There is no Lock, nor difference between Write, Append,
> and Save.  Allowing PM in an HFS subdirectory appears (on the
> surface) to allow no end of mischief, especially should one
> find itself in a web enabled HPe3000 (like my Empire machine),
> and run PM code residing in a simple HFS subdirectory from a
> browser or CGI script?

...snip...

This is a Big Important Issue for people doing POSIX porting.

Most interesting network server daemons require PM in order to bind() to socket
ports less than 1024.  The Unix originals usually want to install into some HFS
/bin directory.  So what we porters end up doing is install the PM NMPRG as
ACCOUNT.GROUP.FOOBAR, then create a symlink called bin/foobar which points to
the real PM file, and all is happy.

Unless you need to link your PM NMPRG with NMXL shared libraries.  MPE requires
that a PM NMPRG *only* be linked with NMXLs that also reside in PM groups.  But
since the /lib/libc.sl NMXL shared library is in HFS and not a PM group, you
cannot link with it in its original location.  So you're forced to copy
/lib/libc.sl to ACCOUNT.GROUP.LIBCSL and link with the copy instead.

This cloning of standard libraries is a Very Bad Thing because the clones won't
be updated when you install MPE patches or updates.

If item #24 passes and becomes implemented, this problem disappears because the
system manager could designate PM-authorized HFS files which would probably
include the standard shared libraries like libc, and so PM NMPRGs could link
with these PM NMXLs without forced cloning.

(Stan, correct me if I'm wrong on the intent here)

- Mark B.

> -----Original Message-----
> From: Stan Sieler [mailto:[log in to unmask]]
>
> Hi,
>
> The current wording on SIGMPE item #24 needs clarification.
>
> It's now:
>
>    24. Currently, programs that require PM must reside in an MPE group.
>        The proposal is to remove this restriction.
>
> It should be:
>
>    24. Currently, programs that require PM must reside in an MPE group.
>        This can be a problem for some programs that want to reside
>        outside a group (i.e., with an HFS name).
>
>        The proposal is to provide a secure method of removing or reducing
>        this restriction.  One possibility would be to have a system manager
>        created list of HFS program files that are allowed to get PM
> capability.
>
> Remember, vote at:
>
>  http://oblina.csillc.com/sigs      or
>  http://207.103.9.100/sigs
>
> --
> Stan Sieler                                           [log in to unmask]
> www.allegro.com/sieler/wanted/index.html                  www.sieler.com

--
[log in to unmask]
Remainder of .sig suppressed to conserve scarce California electrons...