public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Arne Wiebalck <arne.wiebalck@cern.ch>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-scsi@vger.kernel.org
Subject: RE: SG_IO permissions
Date: Fri, 4 Jul 2008 10:13:02 +0200	[thread overview]
Message-ID: <1215159183.5058.200.camel@pcitfio23.cern.ch> (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).

Just to close this thread (and in case someone else comes across 
a similar problem):

A solution that seems to work in this specific scenario is to use 
prctl(2) before the setuid call to keep the capabilities in the
permitted set and to raise CAP_SYS_RAWIO afterwards using 
cap_set_proc(3). 
This way, the user process can again use SG_IO commands for st.
(Thanks to Peter Kelemen for suggesting that.)

Arne  


      parent reply	other threads:[~2008-07-04  8:13 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
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 [this message]

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=1215159183.5058.200.camel@pcitfio23.cern.ch \
    --to=arne.wiebalck@cern.ch \
    --cc=James.Bottomley@HansenPartnership.com \
    --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