COPY/RECORDABLE_MEDIA

[Derek Garson]

The COPY/RECORDABLE_MEDIA doco seems a bit limited. I looked in the DCL Dictionary and it doesn't seem to be there at all! Anyone got a link to some doco?

It also seems to produce errors that aren't recognized by HELP/MESS

A specific question ... what are the minimum privs required?

If there are privs required, what is the best way to avoid the need for those privs?

(I would like selected unpriv'd or minimally priv'd users to be able to burn CDs rather than requiring system-busting privs.)

Installing an image that doesn't expect to be installed is generally a bad idea. On my system the image is already installed with DIAG PHY and SYSLCK. Is that normal?

Based on that, maybe all that an unpriv'd user would need would be access to the device e.g. via an ACL. Or maybe not even that. What access? Are there any risks or downsides with granting that access?

$ HELP COPY/RECORD Restriction

is present but blank, as if it's trying to tell me something.

Itanium; V8.3-1H1

[Steven Schweda]

I use Crdtools/Cdrecord for this stuff, so I
know little (at most) about COPY
/RECORDABLE_MEDIA, but I normally install
cdrecord.exe with ALTPRI, DIAGNOSE, and
PHY_IO. ALTPRI because it tries to boost its
process priority, in the hope of avoiding an
empty buffer old drives which can't cope with
that situation. DIAGNOSE is needed for some
of the more exotic SCSI operations. I don't
remember the justification for PHY_IO, but I
suspect that there is one. Might be in the
same boat as DIAGNOSE. Permission to access
the drive device is helpful, of course. I'm
a one-user operation, so I just put W:RWPL on
my "YAMAHA CRW2100S". (Probably similar on
the other system with the DVD drive.) Unless
someone has SHARE, allocating the device
should be good enough to avoid clashes.

I can imagine that COPY /RECO doesn't bother
with nice(), and it might do some more exotic
locking, about which I know nothing.

I once looked at the COPY /RECO documentation
(or lack thereof), and decided to stick with
Cdrtools.

[Hoff]

The tool does need access to the input and the output, and the tool is (or was) specifically coded and built to operate correctly when installed with added privileges.

During normal OpenVMS operations, the tool is installed with PHY_IO, DIAGNOSE, and SYSLCK privileges via the AUTOGEN stuff and SYS$MANAGER:VMSIMAGES.DAT, etc.

Adding privileges to the installation would not be my first choice; I'd probably look to use a subsystem identifier here.

Here is some related documentation that I've written up:

http://64.223.189.234/node/28

As with most other projects, there is some backstory here, too. But that's fodder for other discussions elsewhere.

[Derek Garson]

From Hoff's post (indirectly), the documentation hides in

HP OpenVMS System Management Utilities Reference Manual: Aâ L (Chapter 9)

Unfortunately it doesn't contain much more than is in the $ HELP

[Steven Schweda]

Re: DIAGNOSE and PHY_IO:

http://h71000.www7.hp.com/doc/73final/6136/6136pro_027.html#index_x_1011

[Heuser-Hofmann]

I've found this:

http://www.digitalsynergyinc.com/openvms_dvd_burning.html

Eberhard

[Derek Garson]

Partly and tentatively answering my own question ... it seems well and truly broken.

The user needs PHY_IO and DIAG even though the image is installed with those privs.

(Granting P access either via the device protection mask or an ACL didn't seem to make any difference. Granting RWPL via an ACL didn't seem to make any difference. Nothing elicited a good error message either.)

So it doesn't seem as if I can easily achieve what I wanted to achieve.

The user doesn't seem to need any actual access to the device. That is, the device is owned by SYSTEM and does not grant any access to W and the non-system-UIC user doesn't have any relevant access privs but with PHY_IO and DIAG the user seems to be able to burn.

If anyone from HP reads this post, COPY/RECORD is in serious need of some work, for everything in this thread and other "funnies" besides.

[Steven Schweda]

> The user needs PHY_IO and DIAG even though
> the image is installed with those privs.

Perhaps they stole too much old cdrecord
code. It (well, my stuff) works right,
these days:

alp $ show symbol cdr*
CDRECORD == "$ UTILITY:CDRECORD.EXE"
CDRX == "$ UTILITY:CDRECORD.EXE;0"

alp $ cdrx QREADCD.TXT dev=cdr
cdrecord: No write mode specified.
cdrecord: Asuming -sao mode.
cdrecord: If your drive does not accept -sao, try -tao.
cdrecord: Future versions of cdrecord may have different drive dependent default
s.
Cdrecord-ProDVD-ProBD-Clone 2.01.01a55 (Alpha-HP-VMS/OpenVMS) Copyright (C) 1995
-2008 Jörg Schilling
cdrecord: Fifo not supported.
scsidev: 'cdr'
devname: 'cdr'
scsibus: -2 target: -2 lun: -2
cdrecord: not all requested privileges authorized. (DIAGNOSE and PHY_IO). Cannot
open or use SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root.
cdrecord: For possible transport specifiers try 'cdrecord dev=help'.

Now, the same program, but installed:

alp $ cdrecord QREADCD.TXT dev=cdr
cdrecord: No write mode specified.
cdrecord: Asuming -sao mode.
cdrecord: If your drive does not accept -sao, try -tao.
cdrecord: Future versions of cdrecord may have different drive dependent default
s.
Cdrecord-ProDVD-ProBD-Clone 2.01.01a55 (Alpha-HP-VMS/OpenVMS) Copyright (C) 1995
-2008 Jörg Schilling
cdrecord: Fifo not supported.
scsidev: 'cdr'
devname: 'cdr'
scsibus: -2 target: -2 lun: -2
Physical device name: _ALP$DKB500:
Using libscg version 'schily-0.9'.
cdrecord: Warning: using unofficial libscg transport code version (SMS-scsi-vms.
c-1.34+SMS '@(#)scsi-vms.c 1.34 06/11/26 Copyright 1997 J. Schilling').
Device type : Removable CD-ROM
Version : 2
Response Format: 2
Capabilities : SYNC
Vendor_info : 'YAMAHA '
Identifikation : 'CRW2100S '
Revision : '1.0K'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-2 SWABAUDIO
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R96R
cdrecord: error 0. test unit ready: scsi sendcmd: retryable error
CDB: 00 C0 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 02 00 00 00 00 0A 00 00 00 00 3A 01 00 00 00 00
Sense Key: 0x2 Not Ready, Segment 0
Sense Code: 0x3A Qual 0x01 (medium not present - tray closed) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.000s timeout 200s
cdrecord: No disk / Wrong disk!
cdrecord: error 0. prevent/allow medium removal: scsi sendcmd: retryable error
CDB: 1E C0 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 03 00 00 00 00 0A 00 00 00 00 0C 0A 00 00 00 00
Sense Key: 0x3 Medium Error, Segment 0
Sense Code: 0x0C Qual 0x0A (write error - padding blocks added) Fru 0x0
Sense flags: Blk 0 (not valid)

(No disc, but I can talk to the drive.)


alp $ show proc /priv

21-JAN-2009 18:01:51.61 User: SMS Process ID: 2020F465
Node: ALP Process name: "SMS_63596"

Authorized privileges:
NETMBX TMPMBX

Process privileges:
NETMBX may create network device
TMPMBX may create temporary mailbox

Process rights:
[...]


It's been a while, but I think I had to fix
something in this neighborhood.

[Steven Schweda]

> It's been a while, but I think I had to fix
> something in this neighborhood.

If I'm reading the archives (6-JUN-2006)
right, the problem in cdrecord was that
simply installing the image with privileges
is not enough. The program (apparently)
needs to do a sys$setprv() to ask for them,
too, and that part was missing from
cdrecord. (My belief is that if your
_process_ has the privileges, then the
program doesn't need to do anything. If the
_image_ has the privileges, then the program
needs to ask. Everything's complicated. The
problem is easy to miss if all the testing
is done by gods.)

It could all be documented somewhere.

Of course, that doesn't fix COPY /RECO. (But
it does suggest a place from which one might
steal some code.)