XBR1Y028@DDATHD21.BITNET (01/07/88)
We observed the following problem under VMS 4.6:
using BACKUP for saving files on tape (for example) by an non-privileged user,
the user gets this obscure error message :
%BACKUP-F-LABELERR, error in tape label processing on MU:[]FOOFOO.BCK;
-SYSTEM-F-BADPARAM, bad parameter value.
We then asked the TSC center.
This is a well known bug under VMS 4.6 they said.
They said BACKUP currently needs the privilege PHY_IO !
There are currently two ways to handle this problem
(there is no patch available - they said) :
a) all users who want to use BACKUP should get this privilege (PHY_IO) ???!!
b) install BACKUP with this privilege (PHY_IO)
We decided to use solution b) !
Unfortunately then BACKUP also refuses to work (even when all privileges are
turned on, like the following command for our daily backup operations):
$ BACKUP /IGNOR=INTERL /REWIND /FAST /RECORD /DENS=6250-
/JOU=THD$OPER1:[BACKUP]BACKUP14.BJL.1 -
USER02:[*...] /SINCE=BACKUP MUA0:6JANBAK.BCK
%DCL-W-ACTIMAGE, error activating image ENCRYPSHR
-CLI-E-IMGNAME, image file DUA0:[SYS0.][SYSLIB]ENCRYPSHR.EXE;3
-SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged
image
Image SYS$LIBRARY:ENCRYPSHR.EXE must also be installed with that privilege!
--> I don't like either solution!
Did anyone out there in netland have the same problems (or are you always using
the system account for BACKUPs) ?
Did you come up with a better/different solution?
Thanks in advance,
Walter
______________________________________________________________________________
Walter Reichenbaecher
Technical University Darmstadt
University Computing Center
Applications / User Support
Darmstadt, West Germany
Bitnet/EARN: XBR1Y028 at DDATHD21
ARPAnet: XBR1Y028%DDATHD21.BITNET@CUNYVM.CUNY.EDU
_______________________________________________________________________________carl@CITHEX.CALTECH.EDU (Carl J Lydick) (01/07/88)
> We observed the following problem under VMS 4.6: > > using BACKUP for saving files on tape (for example) by an non-privileged user, > the user gets this obscure error message : > > %BACKUP-F-LABELERR, error in tape label processing on MU:[]FOOFOO.BCK; > -SYSTEM-F-BADPARAM, bad parameter value. > > We then asked the TSC center. > This is a well known bug under VMS 4.6 they said. > > They said BACKUP currently needs the privilege PHY_IO ! That's odd. We've been running VMS 4.6 for over a month, don't have BACKUP INSTALLed at all, and haven't seen this problem. The account from which we do image backups of our disks every week has only TMPMBX, NETMBX, and BYPASS privs (the last of these is so that we can backup ALL the files on the disk). We have two STC tri-density tape drives hooked up to a SYSTEMS INDUSTRIES controller in such a way that they look like TU45's, but are on the UNIBUS, and use a driver written by SI. > There are currently two ways to handle this problem > (there is no patch available - they said) : > > a) all users who want to use BACKUP should get this privilege (PHY_IO) ???!! > > b) install BACKUP with this privilege (PHY_IO) > > We decided to use solution b) ! > Unfortunately then BACKUP also refuses to work (even when all privileges are > turned on, like the following command for our daily backup operations): > > $ BACKUP /IGNOR=INTERL /REWIND /FAST /RECORD /DENS=6250- > /JOU=THD$OPER1:[BACKUP]BACKUP14.BJL.1 - > USER02:[*...] /SINCE=BACKUP MUA0:6JANBAK.BCK > %DCL-W-ACTIMAGE, error activating image ENCRYPSHR > -CLI-E-IMGNAME, image file DUA0:[SYS0.][SYSLIB]ENCRYPSHR.EXE;3 > -SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged > image > > Image SYS$LIBRARY:ENCRYPSHR.EXE must also be installed with that privilege! > > > --> I don't like either solution! > > Did anyone out there in netland have the same problems (or are you always using > the system account for BACKUPs) ? > > Did you come up with a better/different solution? I could be wrong, but I don't think you have to INSTALL ENCRYPSHR.EXE with privileges; merely INSTALLing it /OPEN/HEADER/SHAR should suffice (I base this claim on the fact that MAIL, which is installed with SYSPRV, can call TPU, and TPUSHR.EXE is installed with no privs). Another thing you could do is to create a captive account that has PHYIO, is in a group by itself, runs only BACKUP, and checks to make sure that the privilege isn't abused. The drawback to this is that in order to do the backups, a user has to protect his files so that this account can read them, which means that anybody using the account can copy his files while he's doing his backup. You can circumvent this difficulty by setting the UAF MAXJOBS field to 1 for this account, so a user can: 1) Log in to the backup account 2) Protect his files from a job running on his own account so he can back them up. 3) Do the backup 4) Reset the protections 5) Log out of the backup account Since his is the only job currently running on that account, his files should be safe, unless the system crashes sometime during the procedure.
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (01/08/88)
... [U]sing BACKUP for saving files on tape (for example) by an non-privileged user, the user gets this obscure error message : %BACKUP-F-LABELERR, error in tape label processing on MU:[]FOOFOO.BCK; -SYSTEM-F-BADPARAM, bad parameter value. We then asked the TSC center. This is a well known bug under VMS 4.6 they said.... BACKUP currently needs the privilege PHY_IO ! I don't remember the details of this exactly, but I think the problem is really in one of the magtape drivers, not in BACKUP as such. ...We decided to [install BACKUP with PHYS_IO, but it fails with the message]: %DCL-W-ACTIMAGE, error activating image ENCRYPSHR -CLI-E-IMGNAME, image file DUA0:[SYS0.][SYSLIB]ENCRYPSHR.EXE;3 -SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image Image SYS$LIBRARY:ENCRYPSHR.EXE must also be installed with that privilege! ... No; it need merely be INSTALL'ed. No privileges are required, and in fact installing a shareable image WITH privileges is meaningless - the privileges will never be used for anything. INSTALL'ing SYS$LIBRARY:ENCRYPSHR.EXE is quite safe. Since the problem only comes up with backups directly to tape, installing BACKUP with PHYS_IO may be overkill. Giving a user PHYS_IO is dangerous, since with that privilege it is possible to do I/O's to the "raw disk" and scribble over any file you like. Giving BACKUP PHYS_IO is PROBABLY safe, since BACKUP isn't about to do random physical I/O's to the disk, no matter what you ask it to do. Possibly, it will be able to override some tape protections; it would take a real close look to be sure. I suspect there's really no perfect solution to the problems this bug causes; you'll have to evaluate your situation yourself. A lot depends on how often non-privileged users need to do backups to tapes. At many installations, this is rather rare - operators do regular backups, either from SYSTEM (or, prefer- ably) from special, controlled accounts that can be given PHYS_IO with only a very small added security exposure. Most users make limited use of tapes, and when they use them they don't write backups, but use some sort of appli- cation that deals with the tape directly. Other installations may have users who write backup tapes all the time - to do distributions, for example. These obviously will need a different approach - perhaps each such user can be given a second, captive account, which has PHYS_IO but is set up so that it can only be used to run BACKUP. -- Jerry
tihor@acf4.UUCP (Stephen Tihor) (01/08/88)
Its TMSCP devices only according to the earlier message on the subject.
darin@laic.UUCP (Darin Johnson) (01/09/88)
In article <880106185356.00b@CitHex.Caltech.Edu>, carl@CITHEX.CALTECH.EDU (Carl J Lydick) writes: > > > They said BACKUP currently needs the privilege PHY_IO ! > > That's odd. We've been running VMS 4.6 for over a month, don't have BACKUP > INSTALLed at all, and haven't seen this problem. According to DEC (we have this problem also), it is only a problem with the TU81 (or TU81+) tape drives. A DEC person said that the bug was never noticed since the people writing/testing the code always logged in with all priviliges enabled :-o -- Darin Johnson (..sun!sunncal!leadsv!laic!darin) All aboard the DOOMED express!