jhull@spp2.UUCP (Jeff Hull) (04/10/85)
In article <504@sal.UUCP> jf@sal.UUCP (Johan Finnved) writes: >Possible implementation suggestions: > >... It starts by >rewinding the tape and checking its volume label in order to make sure >that this user (real uid) has really the right to use this tape. ... >Does anybody have ideas on what to put in the fields for Owner >Identifier (in VOL1 lables), Accessibility (In VOL1 and HDR1-EOV1-EOF1 >labels) and System Code (in HDR1-EOV1-EOF1 labels) ? Just be sure that, for those cases when I take my tape to your site, I can read & write to my tape without requiring recourse to superuser capabilities. (The loginid & userid probably will be different. Very often, my userid on my system will be assigned to someone else on your system.) -- Blessed Be, Jeff Hull {decvax,hplabs,ihnp4,scdrdcf,ucbvax} 13817 Yukon Ave. trwrb!trwspp!spp2!jhull Hawthorne, CA 90250 34o3'15" N by 118o14'28" W
jf@sal.UUCP (Johan Finnved) (04/11/85)
There has been some talk on the net about protecting people from writing on wrong tapes. So far it has been assumed the nobody mounts the wrong tape on a tape drive which is not always correct. There has also been a package for reading and writing ANSI-tape recently but without multiple volume handling and without enforcement of protection. I think that an implementation of the ANSI standard for Tape Labels and File Structure for Information Interchange (X3.27-1978) would solve several problems. Most notably positive tape identification and continuation of big files on multiple volumes (without having applications to limit their output). I think that this could also solve the problem of two users accidently using the same tape drive. Possible implementation suggestions: The driver is helped by a tape managing program which handles labels and blocks-unblocks data. Data is moved between tapes and files or pipes. The raw device is not accessible by ordinary users. The driver allows only one open at a time, and the server does only one open and thus knows that nobody can interfere with its tapehandling. It starts by rewinding the tape and checking its volume label in order to make sure that this user (real uid) has really the right to use this tape. There has to be IOCTL:s for tape positioning, rewinding ,writing of tapemarks and for forcing writes after EOT. I think it is most efficient to allow reads until a few blocks after EOT and writes up to EOT and then let the first after EOT has been seen return an error (or zero count) and then have an ioctl that allows you to write a few blocks more to make the volume finish correctly. The tape managing program is set-uid "tape". Has anybody assigned IOCTL subfunctions for the above magtape commands ? Does anybody have ideas on what to put in the fields for Owner Identifier (in VOL1 lables), Accessibility (In VOL1 and HDR1-EOV1-EOF1 labels) and System Code (in HDR1-EOV1-EOF1 labels) ? Maybe somebody has already assigned codes in some other system? (VMS?) Unfortunately the fields seems to be too short for domain type identifiers (site.subdomain.subdomain.DOMAIN) Johan Finnved, Objecta, Sweden <jf@sal.UUCP>
herbie@watdcsu.UUCP (Herb Chong [DCS]) (04/14/85)
In article <533@spp2.UUCP> jhull@spp2.UUCP (Jeff Hull) writes: >In article <504@sal.UUCP> jf@sal.UUCP (Johan Finnved) writes: >>Possible implementation suggestions: >> >>... It starts by >>rewinding the tape and checking its volume label in order to make sure >>that this user (real uid) has really the right to use this tape. ... >>Does anybody have ideas on what to put in the fields for Owner >>Identifier (in VOL1 lables), Accessibility (In VOL1 and HDR1-EOV1-EOF1 >>labels) and System Code (in HDR1-EOV1-EOF1 labels) ? > >Just be sure that, for those cases when I take my tape to your site, I >can read & write to my tape without requiring recourse to superuser >capabilities. (The loginid & userid probably will be different. Very >often, my userid on my system will be assigned to someone else on >your system.) > >-- > Blessed Be, > > Jeff Hull {decvax,hplabs,ihnp4,scdrdcf,ucbvax} > 13817 Yukon Ave. trwrb!trwspp!spp2!jhull > Hawthorne, CA 90250 34o3'15" N by 118o14'28" W most places i know map the tape volume identification to an owner on the system that is being used on and the tape access routines verify permissions before opening the tape file as in regular disk file permission checking. this requires an online tape registry and a method for the owner to change permissions on the tape. Herb Chong... I'm user-friendly -- I don't byte, I nybble.... UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie CSNET: herbie%watdcsu@waterloo.csnet ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa NETNORTH, BITNET, EARN: herbie@watdcs, herbie@watdcsu
stern@bnl.UUCP (Eric Stern) (04/15/85)
> In article <504@sal.UUCP> jf@sal.UUCP (Johan Finnved) writes: > >Possible implementation suggestions: > > > >... It starts by > >rewinding the tape and checking its volume label in order to make sure > >that this user (real uid) has really the right to use this tape. ... > >Does anybody have ideas on what to put in the fields for Owner > >Identifier (in VOL1 lables), Accessibility (In VOL1 and HDR1-EOV1-EOF1 > >labels) and System Code (in HDR1-EOV1-EOF1 labels) ? > > Just be sure that, for those cases when I take my tape to your site, I > can read & write to my tape without requiring recourse to superuser > capabilities. (The loginid & userid probably will be different. Very > often, my userid on my system will be assigned to someone else on > your system.) The volume label contains a field for accessability and a machine dependent field for owner identification. In VMS, if the system determines that the tape was written on a DEC system, the owner identification field contains the owner's identity and volume protection information. Volume protection can be granted in the same way as file protection works, so read and write permission can be allowed or disallowed to members of the owners group, and the general world. At mount time, the information is checked and access is granted/denied appropriately. Of course someone with system priviledges can overide this. I presume that if the volume was not generated on a DEC computer, the system allows full access. Because the user identifier and file protection concepts are so similar on UNIX and VMS, something similar ought to be possible on UNIX. The information on what VMS writes in tape labels in contained in the back of the RMS reference manual. This includes the standard ansi stuff as well as the DEC specific stuff. They also give the formats for laying out tapes multiple tape volume sets, and multiple volume files. Eric G. Stern ..!philabs!sbcs!bnl!stern stern@bnl.arpa stern@bnl.bitnet