Excerpts from netbsd: 16-Jul-98 Re: OK to allow raw SCSI re.. "Perry E.
Metzger"@pierm (585*)
Excerpts from netbsd: 16-Jul-98 Re: OK to allow raw SCSI re.. Jason
Thorpe@nas.nasa.go (618)
Excerpts from netbsd: 16-Jul-98 Re: OK to allow raw SCSI re.. Matthew
Jacob@feral.com (1117*)

> Should the raw scsi commands not be conditionalized on being in a low
> enough secure level, for obvious reasons?

I think the securelevel should not apply to this.
The tape access does not affect overall system
security as eg a disk does. Unless you have a file system
mounted from tape... Is this still supposed to work?
My proposed change does not make the system less secure
than before (it makes it just more convinient to mess up the
tape :-).

> no, the restriction should be "have device open for writing, unless command
> doens't change the device's state".

> No- it's hard to say how that could be implemented. It might
> be a vendor unique command (e.g., for a stacker).

That's what I think too.
Btw, what the current code (scsipi_do_ioctl) does:
		if ((((scsireq_t *)addr)->flags & SCCMD_READ) == 0 &&
		    (flag & FWRITE) == 0)
			return (EBADF);
is useless imho, because one can eg write filemarks without
transferring data from userspace.

Some options to allow the system administrator to implement
a more finegrained access control are:
-Require write permission for any raw commands. That's not
  ideal in the stacker case.
-Abuse the execute permission bit as "raw access allowed".
-Use another bit in the minor number for this.

best regards
Matthias