Re: Apache + mod_php performance

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.