From:	SMTP%"ejon@ll.mit.edu" 18-MAY-1994 18:51:11.87
To:	EVERHART
CC:	
Subj:	Re: New device protections under VMS V6.0

X-Newsgroups: comp.os.vms
From: ejon@ll.mit.edu (Eric Jones)
Subject: Re: New device protections under VMS V6.0
Message-ID: <1994May18.192115.24440@ll.mit.edu>
Keywords: VMS 6.0, dumb
Sender: ejon@ll.mit.edu (Eric Jones)
Reply-To: ejon@ll.mit.edu (Eric Jones)
Organization: MIT Lincoln Laboratory
Date: Wed, 18 May 94 19:21:15 GMT
Lines: 59
To: Info-VAX@CRVAX.SRI.COM
X-Gateway-Source-Info: USENET


In article <1994May18.152925.14502@ll.mit.edu>, ejon@ll.mit.edu (Eric Jones) writes:

[omitted for brevity]

|>are the same for all three devices (except for device name):
|>
|>$ sho sec mua0:/class=dev
|>
|>_DC$MUA0: object of class DEVICE
|>     Owner: [SYSTEM]
|>     Protection: (System: RWPL, Owner: RWPL, Group: R, World: RWPL)
|>     Access Control List: <empty>
|>

Woops, this turned out to be wrong.  In fact, for the devices which AREN'T
working, I get:

$ sho sec/class=dev mua1:

_DC$MUA1: object of class DEVICE
     Profile is being resolved by the object server
     Owner: [SYSTEM]
     Protection: (System: RWPL, Owner: RWPL, Group: R, World: RWPL)
     Access Control List: <empty>

Derrell, (PIPER@tgv.com), who was apparently involved in the development
of the security software when he was at DEC sent me a mail message which
I think many of us will find educational.  I include it (edited) below with
permission:

>I wrote:
Derrell wrote:
>> And SHOW SECURITY MUA2:/CLASS=DEVICE yields :
>> 
>> _DC$MUA2: object of class DEVICE
>>      Profile is being resolved by the object server
>>      Owner: [SYSTEM]
>>      Protection: (System: RWPL, Owner: RWPL, Group: R, World: RWPL)
>>      Access Control List: <empty>

> "Profile is being resolved by the object server" is the key.  This indicates
> that the object server (a thread within the audit server process) has not
> yet finished setting the profile for a cluster visible device.  The object
> server is charged with ensuring that cluster visible security profiles are
> kept consistent across a cluster.  What defines a cluster visible device is
> based on device type, not actual visibility.

> The protection for cluster visible disks and tapes is stored in a backing
> file (SYS$SYSTEM:VMS$OBJECTS.DAT).  While the object server is fetching the
> profile from disk a "transition" flag is set which results in this message.
> You shouldn't be in this state except during the boot sequence.  However,
> when an object is in this state, VMS denies all non-privileged access to the
> object because it does not believe that the protection on the object is
> necessarily valid (fail-safe).

> I think you've run into a bug in V6.0.  I recall that we fixed a problem
> with non-shared tape device protection post-V6.0 (before I left DEC).  I
> think you can get a patch from Colorodo to fix this in V6.0.