On Wed, 2008-07-02 at 20:40 +0200, Arne Wiebalck wrote: > >>> 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? > > The user process in my case is forked by another process which runs > as root. But since this process does not have CAP_SETPCAP it cannot > set the child's capabilities (which is how I naively thought one could > implement this). > > What options are left? Running a patched kernel where the "SG_IO in st > requires CAP_SYS_RAWIO" is taken out? Erm, well capabilities are designed to be malleable, especially with things like sucap and execap, which root should be able to use. I'm not really an expert on the best way to use capabilites, but there's a nice faq on kernel.org. James -- 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
