[Info-vax] Caution: LTT ignores ALLOCATE

[Johnny Billquist]

On 2011-10-06 16.55, Dale Dellutri wrote:
> On Wed, 5 Oct 2011 16:12:29 -0700 (PDT), Bob Gezelter<gezelter at rlgsc.com>  wrote:
>> On Oct 5, 10:36?am, Dale Dellutri<ddelQQQl... at panQQQix.com>  wrote:
>>> I use LTT (Library and Tape Tool) to test tape drives and cartridges.
>>> I just discovered that it ignores the fact that another processes may
>>> have exclusive access to the drive via the ALLOCATE command.
>>>
>>> LTT is clearly not originally written for OpenVMS, and it shows.
>
>> Dale,
>> Some more details would be helpful. Including:
>> - URL of product description
>> - a full SHOW PROCESS of your process
>> - a listing of the account used from the SYSUAF (including all
>> privileges and rights)
>> - a SHOW DEVICE/FULL for the tape drive in question
>> It could be a poor port, or there could be other reasons. Without data
>> there cannot be a definitive diagnosis.
>> - Bob Gezelter, http://www.rlgsc.com
>
> I didn't mean to start a long thread about this.  I was just surprised
> that LTT ignored the allocate, and wanted to warn others so that they
> would be cautious using LTT.
>
> I logged in as SYSTEM, allocated the drive, loaded a cartridge,
> and did some tape manipulations.  (The cartridge was new, and will
> be used as a backup tape.)
>
> =====
> $ allocate mkd600:
> %DCL-I-ALLOC, _XX$MKD600: allocated
> $ init mkd600: DAILY4
> $ mou/for/noass mkd600:
> %MOUNT-I-MOUNTED, DAILY4 mounted on _XX$MKD600:
> $ dism /nounl mkd600:
> $ sho dev mkd600: /full
>
> Magtape XX$MKD600:, device type COMPAQ SDLT320, is online, allocated, record-
>      oriented device, file-oriented device, available to cluster, error logging
>      is enabled, controller supports compaction (compaction  disabled), device
>      supports fastskip (per_io).
>
>      Error count                  159    Operations completed         1702975163
>      Owner process           "SYSTEM"    Owner UIC                    [SYSTEM]
>      Owner process ID        000BF851    Dev Prot    S:RWPL,O:RWPL,G:RWPL,W:RWPL
>      Reference count                1    Default buffer size                 512
>      Density                  default    Format                        Normal-11
>
>    Volume status:  no-unload on dismount, beginning-of-tape, odd parity.
> =====
>
> Note that I didn't deallocate the drive and I didn't log out.
>
> Then I opened a second window and logged in separately again
> to SYSTEM, and tried some vms commands ...
>
> =====
> $ allocate mkd600:
> %SYSTEM-W-DEVALLOC, device already allocated to another user
> $ init /med=com mkd600: DAILY4
> %SYSTEM-W-DEVALLOC, device already allocated to another user
> =====
>
> ... and, as expected, these commands respect the fact that
> another process has allocated the drive.  However, I then
> started LTT in this second login, and it ran a read/write
> test on the cartridge in the drive without complaint or
> even warning.  I'm using version 4.13 of LTT (URL below
> is wrapped):
>
> =====
> http://h20000.www2.hp.com/bizsupport/TechSupport/
>    DriverDownload.jsp?
>    pnameOID=406731&locale=en_US&taskId=135&
>    prodTypeId=12169&prodSeriesId=406729
>
> HP StorageWorks Library and Tape Tools (Alpha)
> Type:	Diagnostic
> Version:	4.13 SR1 (14 Sep 2011)
> Operating System(s):	OpenVMS, OpenVMS v7.3-2,
>   OpenVMS v8.2, OpenVMS v8.3, OpenVMS v8.4
> File name:	hp-axpvms-ltt-v0413-0-1.zipexe (12 MB)
> =====
>
> If you don't want to reconstruct the URL above, just
> google for
>    hp openvms library tape tool
>
> The SYSTEM account has its usual privileges.  And the system is:
>
> =====
> $ sho sys /noproc
> OpenVMS V8.2 on node XX 6-OCT-2011 09:15:02.24  Uptime 542 15:16:07
> =====

And if you check what privileges the SYSTEM user have, you'll notice 
that it have SHARE, which means it can assign channels to non-shared 
devices. Ie. it can bypass the allocate status of a device.

This has nothing to do with the LTT, and everything to do with who you 
are and what privileges you have.

This was what the original questioner asked about first of all. Do the 
user have the SHARE privilege. (Asked by, by asking for the result of 
the command

pipe show proc /priv | sear sys$input " share "

So it had everything to do with who you define "others" as, since 
obviously there are "others" who have more rights than a normal user, 
and thus can bypass all the protections you can think of.
And all of this is done within VMS, and the device driver, or other code 
is not involved in it.

So, now you know a bit more about VMS. :-)

	Johnny