Operating System - OpenVMS
1753903 Members
9742 Online
108810 Solutions
New Discussion юеВ

Re: Problem with Temporary Mail Box

 
John Gillings
Honored Contributor

Re: Problem with Temporary Mail Box

re Jan:

>Just be aware that ANYBODY _WRITING_
>anything in that mailbox now requires
>GRPNAM privilege!

Not true. GRPNAM is required to CREATE the mailbox because part of the creation involves defining a logical name in LNM$GROUP. Once the mailbox exists, anyone in the group can *translate* the logical name without privilege. Assigning a channel to, reading or writing the mailbox is controlled by the security of the mailbox, which is completely independent of the LNM$TEMPORARY_MAILBOX logical name. There's a PROTMASK parameter to $CREMBX, and of course, a mailbox may have an ACL.

According to the documentation, the default protection of a mailbox comes from the "mailbox template", but I can't find one on a V8.3 system (see SHOW SECURITY/CLASS=SECURITY_CLASS *), nor does the command to change it seem to work:

$ SET SECURITY /CLASS=SECURITY_CLASS /PROFILE=TEMPLATE=MAILBOX /PROTECTION=(S:RWPL,O:RWPL,G,W) DEVICE

Regardless I still get mailboxes with W:RWPL access by default.

A crucible of informative mistakes
John Gillings
Honored Contributor

Re: Problem with Temporary Mail Box

>"mailbox template", but I can't find one >on a V8.3 system

Found it...

$ show security/class=security device

DEVICE object of class SECURITY_CLASS
Owner: [SYSTEM]
Protection: (System: RW, Owner: RW, Group: R, World: R)
Access Control List:

Template: DISK
Owner: [SYSTEM]
Protection: (System: RWPL, Owner: RWPL, Group: R, World)
Access Control List:
...

Template: MAILBOX
Owner: [0,0]
Protection: (System: RWPL, Owner: RWPL, Group: RWPL, World: RWPL)
Access Control List:
...


but I still can't make it work!


Template: MAILBOX
Owner: [0,0]
Protection: (System: RWPL, Owner: RWPL, Group, World)
Access Control List:

(so group and world are no access)

but..

$ create/mailbox newmbx
$ show dev/full newmbx

Device MBA58676:, device type local memory mailbox, is online, record-oriented
device, shareable, mailbox device.

Error count 0 Operations completed 0
Owner process "" Owner UIC [OM_PROD]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:RWPL,W:RWPL
Reference count 1 Default buffer size 256


which doesn't match the protection in the template. Putting an explicit protection on the $CREMBX does as expected:

$ create/mailbox mbx2/prot=(s:rwpl,o:rwpl,g:rw,w)
$ show dev/full mbx2

Device MBA58680:, device type local memory mailbox, is online, record-oriented
device, shareable, mailbox device.

Error count 0 Operations completed 0
Owner process "" Owner UIC [OM_PROD]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:RW,W
Reference count 1 Default buffer size 256


The security templates are so well buried in the depths of the OS, I guess not enough people use them, and maybe they still have a few bugs?
A crucible of informative mistakes
Hoff
Honored Contributor

Re: Problem with Temporary Mail Box

John: Make sure VMS$OBJECTS is shared across all nodes in a cluster; that if there are multiple system disks, that there is a definition (usually) in SYLOGICALS that points to one central copy of this file. (I've seen multiple copies of the file lead to weirdness.)
John Gillings
Honored Contributor

Re: Problem with Temporary Mail Box

Hoff,

> shared across all nodes in a cluster

Remember you're talking to Mr "Let's hassle OpenVMS engineering about very poor built in management of cluster common environment files" ;-) I probably reported some of those "multiple copies of the file lead to weirdness". :-)

(besides, the node in question is standalone)
A crucible of informative mistakes
Jan van den Ende
Honored Contributor

Re: Problem with Temporary Mail Box

John,

>>>
Not true. GRPNAM is required to CREATE the mailbox because part of the creation involves defining a logical name in LNM$GROUP.
<<<

Thank you! One is never too old to learn. This DOES give me the means to determine which privileges can be revoked from which users without breaking an application.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Willem Grooters
Honored Contributor

Re: Problem with Temporary Mail Box

Just A Thought:

Given the temporary mailbox name will be in the GROUP table (assuming you gave the mailbox a name in P1, that is known by P2..P10), processes P2..P10 must run in the same UIC group. If such a process runs in another UIC group, that name will not be translated (correctly) - hence IVDEVNAM.

My first question would be:
how does p2 know the name of the mailbox to use? hardcoded logical name?

You stated:

P2 came to know the mailbox using a logical, its not hardcoded logical, logical value will depend on the mailbox name created by the process p1.

I hope my understanding is correct: (values just examples):

P1 creares a mailbox _named_ "P1_INMBX", rsulting in device "_MB1234". In LNM$GROUP, a logical "P1_INMBX" will be created with content "_MB1234" - after the mailbox has been created. P2..P10 will search LNM$GROUP for "P1_INMBX", if found they get device "_MB1234" and assign a channel to it. If it is missing, there is no such device and no assignment will take place. Action depends: Wait and retry, or abort.

That would rule out synchornisation problems, I think.
Willem Grooters
OpenVMS Developer & System Manager
Not applicable

Re: Problem with Temporary Mail Box

regards,
ajaydec