From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Arne Wiebalck <Arne.Wiebalck@cern.ch>
Cc: linux-scsi@vger.kernel.org
Subject: RE: SG_IO permissions
Date: Wed, 02 Jul 2008 15:28:54 -0500 [thread overview]
Message-ID: <1215030534.3330.46.camel@localhost.localdomain> (raw)
In-Reply-To: <E7F3663B89B60B478C6997C0A0671F8B0D58AB@cernxchg45.cern.ch>
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
next prev parent reply other threads:[~2008-07-02 20:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-02 13:20 SG_IO permissions Arne Wiebalck
2008-07-02 14:51 ` James Bottomley
2008-07-02 18:00 ` Arne Wiebalck
2008-07-02 18:40 ` Arne Wiebalck
2008-07-02 20:28 ` James Bottomley [this message]
2008-07-03 9:15 ` Arne Wiebalck
2008-07-03 15:06 ` James Bottomley
2008-07-03 17:57 ` KELEMEN Peter
2008-07-04 8:13 ` Arne Wiebalck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1215030534.3330.46.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=Arne.Wiebalck@cern.ch \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox