Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rochester!rutgers!sri-spam!ames!ucbcad!ucbvax!GRIN2.BITNET!MCGUIRE
From: MCGUIRE@GRIN2.BITNET
Newsgroups: comp.os.vms
Subject: RE: spawned privs
Message-ID: <8708041941.AA00876@ucbvax.Berkeley.EDU>
Date: Mon, 3-Aug-87 10:08:00 EDT
Article-I.D.: ucbvax.8708041941.AA00876
Posted: Mon Aug  3 10:08:00 1987
Date-Received: Thu, 6-Aug-87 04:14:54 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 50

> Date:         30 Jul 87 06:22:32 EDT
> From:         *Hobbit* <AWalker@RED.RUTGERS.EDU>
> Subject:      spawned privs
>
> For testing things in an environment where it can't "grab" any extra
> privileges, copying the CUR to the AUTH mask of the spawned process is the
> quite corrrect behavior.
>
> the privilege passing mechanism as it stands is a good way to reliably deny
> yourself privs for a process.

(Realistically, how many times a day do you really spawn a subprocess to test
something with privileges denied?  I mean, either you or an associate has
written the code, and you _know_ that it doesn't elevate privs, or you're
testing code you don't have control over--and your testing won't tell you if
it _does_ elevate privs when they are available!)

There are two common reasons to spawn, each of which actually has virtually
opposing privilege copy requirements.

1.  I spawn many, many times each day, to do one operation or another without
    losing my context. For these operations what I really want is a separate
    process that behaves more or less as if it was created from scratch.  It
    annoys me that my symbols, logical names, etc. are copied but my privilege
    masks are not preserved.  The specific annoyance is that I'll have changed
    my privs and then I gotta go to another terminal just because I can't turn
    on an authorized priv.

    No programmer on our staff has ever asked, `how can I create a subprocess
    that has no privileges?'  The question I get from every new programmer very
    early on is, `hey, how come I can't turn on my privileges in the
    subprocess?  I was able to do it yesterday!' or `hey, how come BYPASS stayed
    on when I reset my privileges to normal?  I just blew something away because
    I thought I just turned off all privs!'

    (The second complaint is a natural side-effect of the symbol we've defined
    for programmers that does SET PROC/PRIV='F$GETJPI("","AUTHPRIV")'.)

2.  Applications that are installed with privs and need a subprocess for some
    reason (aside from providing a convenient SPAWN, which comes under category
    1) certainly ought to have complete control over the environment of the
    subprocess, including privs.  Of course, under the current setup, it does
    have control.  Often, it's going to call $CREPRC directly anyway, and
    specify exactly what privs it wants.

I think everyone would be satisfied if LIB$SPAWN had an _option_ to create the
subprocess by $CREPRC'ing with the parent's AUTHPRIV as the initial subprocess
privs, then used the same interface with DCL that it now uses to copy symbols,
etc., to set CURPRIV to the parent's CURPRIV.
---- Ed McGuire, Systems Coordinator, Grinnell College, MCGUIRE@GRIN2.BITNET