SG_IO permissions

SG_IO permissions

[Arne Wiebalck]

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.


TIA,
 Arne




 

Re: SG_IO permissions

[James Bottomley]

On Wed, 2008-07-02 at 15:20 +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.

James

RE: SG_IO permissions

[Arne Wiebalck]

>> 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

RE: SG_IO permissions

[Arne Wiebalck]

>>> 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?

Cheers,
 Arne

RE: SG_IO permissions

[James Bottomley]

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

RE: SG_IO permissions

[Arne Wiebalck]

On Wed, 2008-07-02 at 15:28 -0500, James Bottomley wrote:
> 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.

But you need to change and recompile your kernel to use that, as init
needs CAP_SETPCAP to be set, no?

Cheers,
 Arne

RE: SG_IO permissions

[James Bottomley]

On Thu, 2008-07-03 at 11:15 +0200, Arne Wiebalck wrote:
> > > >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.
> 
> But you need to change and recompile your kernel to use that, as init
> needs CAP_SETPCAP to be set, no?

Well .. how you do that isn't really a SCSI problem.  The FAQ has one
solution.  I suppose rebuilding your kernel is another possible but
inelegant one.

James

Re: SG_IO permissions

[KELEMEN Peter]

* Arne Wiebalck (arne.wiebalck@cern.ch) [20080702 20:40]:

> 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).

There is no need.  Your problem is that setuid() clears the
permissible capability set.  This should do the trick:

	/* ...in child after fork()... */
	prctl(PR_SET_KEEPCAPS, 1, 0, 0, 0);
	setuid(...);
	cap_set_proc(cap_from_text("cap_sys_rawio+ep"));

HTH,
Peter

-- 
    .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
 Kelemen Péter     /       \       /       \     Peter.Kelemen@cern.ch
.+'         `+...+'         `+...+'         `+...+'         `+...+'
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: SG_IO permissions

[Arne Wiebalck]

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