>> Hi all, >> >> I am trying to replace some read/write calls in our application >> by SG_IO commands in order to have access to the sense bytes in >> case of an error. The underlying devices are tape drives. >> >> Part of our application, such as positioning or reading labels >> from the tape, are run as root. This seems to work fine, I get >> the data I expect and the sense bytes in case of an error. >> >> However, the actual data transfer from and to the device is run >> under a user's ID. This part does not work anymore when switching >> from read/write to SG_IO: 'Operation not permitted'. >> >> Does a user need some special rights to issue SG_IO (read) commands >> (on a file descriptor that he opened for reading and that he >> can use without problems for read() calls)? >> >> The device node that the processes are accessing is a char special >> file owned by the user and with all user bits set. This special file >> is created on a per tape request basis. I also tried to use /dev/nst0 >> instead, but that made no difference. >> >> I am running a relatively old kernel (2.6.9 based), could that cause >> any problem? >> >> BTW, why does it say "except st" on the permission requirements table on >> http://sg.torque.net/sg/sg_io.html ? :) >> >> >> Any hints appreciated. > >SG_IO access requires CAP_SYS_RAWIO to defeat the command verifier. > Thanks for the quick reply, James. We're talking about this snippet of code from st.c, I guess? --- switch (cmd_in) { case SCSI_IOCTL_GET_IDLUN: case SCSI_IOCTL_GET_BUS_NUMBER: break; default: if ((cmd_in == SG_IO || cmd_in == SCSI_IOCTL_SEND_COMMAND || cmd_in == CDROM_SEND_PACKET) && !capable(CAP_SYS_RAWIO)) i = -EPERM; else i = scsi_cmd_ioctl(file, STp->disk->queue, STp->disk, cmd_in, p); if (i != -ENOTTY) return i; break; } --- Obviously. (I just found the discussion about this dating from April '05). What's the way to go then in order to access a tape as a user, when the user would like to get the sense bytes in case of problems? Should the user process get CAP_SYS_RAWIO? TIA, Arne -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
