Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.os.vms
Subject: Re: Apache + mod_php performance
Date: Fri, 11 Oct 2024 18:56:53 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vebsdl$rmu$1@reader1.panix.com>
References: <vcv0bl$39mnj$1@dont-email.me> <vebjse$3nq13$1@dont-email.me> <vebo7q$5b8$1@reader1.panix.com> <vebqjs$3oaus$1@dont-email.me>
Injection-Date: Fri, 11 Oct 2024 18:56:53 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="28382"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 4325
Lines: 77

In article <vebqjs$3oaus$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
>
>On 10/11/24 12:45 PM, Dan Cross wrote:
>> In article <vebjse$3nq13$1@dont-email.me>,
>> Dave Froble  <davef@tsoft-inc.com> wrote:
>>> On 10/11/2024 9:30 AM, Dan Cross wrote:
>>>> [snip]
>>>> As I gather, on VMS the analogous mechanism works since a) every
>>>> socket on the system is associated with a unique device name in
>>>> some global namespace, and b) once known, an unrelated process
>>>> can $ASSIGN that device name, subject to authorization checking
>>>> enforced by the system.  The authorization checks seem to be
>>>> either, a) a process/subprocess relationship, or b) the
>>>> assigning process has the SHARE privilege; it's not clear to me
>>>> what else could go into those checks and how that interacts with
>>>> e.g. SO_SHARE; presumably at least UIC checks or something must
>>>> be completed?

Just to be clear, because I think there may be some confusion,
but nowhere above was I suggesting that the `SHARE` _privilege_
is the same as the `SO_SHARE` _option_ on a socket.

>>> The share flag is for the device.
>> 
>> Ok, sure.  But does that mean that there's _no_ authorization
>> checking of any kind to access the device?  For example, no
>> checking UICs or ACLs or something?  If I set SO_SHARE on a
>> socket, can _any_ process on the system, regardless of who it is
>> running as, access that socket?
>
>$ show device/full
>
>on any BG device shows normal-looking device protections just as you
>would see on any other device, e.g.:
>
>Dev Prot    S:RWPL,O:RWPL,G:RWPL,W:RWPL

Interestingly, for BG devies, they're _all_ the same, with the R
bit set for everyone, which, if they just used the default
scheme, would mean that any socket device was ASSIGNable to
anyone, right?  That does not sound correct.  For example, here
is an `ssh` socket on Eisner:

|Device BG8729:, device type unknown, is online, record-oriented device, network
|    device, mailbox device.
|
|    Error count                    0    Operations completed                210
|    Owner process        "SSHD 0012"    Owner UIC                      [SYSTEM]
|    Owner process ID        00003C50    Dev Prot    S:RWPL,O:RWPL,G:RWPL,W:RWPL
|    Reference count                2    Default buffer size                 256

Surely the device protection field here is misleading, at best?

>I don't think socket sharing is a privilege any more than file sharing
>is; more likely it's just a hint to the driver that it needs to do extra
>work to keep its internal state consistent when two processes are
>accessing it.

That seems right, given what we've seen.  Anyway, I think this
put's to rest Arne's assertion that there's no way to give some
process access to a socket created by another process.

>There is an old Ask-the-Wizard article about socket sharing that uses a
>mailbox to send the BG device name to the child process:
>
>https://forum.vmssoftware.com/viewtopic.php?f=35&t=3511&p=7513
>
>The example code sends UCX$C_SHARE using the QIO interface rather than
>SO_SHARE and setsockopt(); I'm guessing it amounts to the same thing but
>I can't find current relevant documentation for either.

I saw that; most of the solutions in this space look more or
less the same.  I confess I remain mystified by the seeming lack
of an authorizaton mechanism, however.

	- Dan C.