cdrecord in -current - Slackware

This is a discussion on cdrecord in -current - Slackware ; Hi, I recently upgraded to -current and cdrecord has stopped working, along with all the apps that use it as a backend. It bails out with "/usr/bin/cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl". Setting cdrecord suid root ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: cdrecord in -current

  1. cdrecord in -current

    Hi,

    I recently upgraded to -current and cdrecord has stopped working,
    along with all the apps that use it as a backend.

    It bails out with "/usr/bin/cdrecord: Operation not permitted. Cannot
    send SCSI cmd via ioctl".

    Setting cdrecord suid root solves the problem, but I don't recall
    having to do this in previous slackware versions (I could be wrong,
    which would explain why it has stopped working).

    Browsing through the changelog I see that Pat has moved k3b to main
    because there's a compile time flag now that disables it asking to set
    cdrecord suid root.

    I remember a few years back all the hoopla around cdrtools with the
    kernel folks, but I thought this was long since solved, at least it
    hasn't been an issue I have run across in other distros for a looong
    time before today with slack.

    So my question is this: is anyone else running into this problem? And
    if this is still expected behavior, what is the best way to deal with
    it? Just set cdrecord suid root? (yuck) I'm already in the cdrom
    group, so accessing the device itself isn't a problem.

    Cheers


  2. Re: cdrecord in -current

    spam.lounge@gmail.com wrote:
    > Hi,
    >
    > I recently upgraded to -current and cdrecord has stopped working,
    > along with all the apps that use it as a backend.
    >
    > It bails out with "/usr/bin/cdrecord: Operation not permitted. Cannot
    > send SCSI cmd via ioctl".
    >
    > Setting cdrecord suid root solves the problem, but I don't recall
    > having to do this in previous slackware versions (I could be wrong,
    > which would explain why it has stopped working).
    > ...


    I've always had to set cdrecord, mkisofs, and readcd setuid root if I
    wanted to burn and copy CDs as non-root users. (mkisofs needs to be
    setuid root for working with multisession CDs.)

    But I totally gave up on cdrtools/cdrecord/mkisofs when I switched to the
    2.6 kernel in Slackware 11.0. Besides the setup problems (setuid or
    not), I got tired of the anti-Linux messages from it. Got cdrkit instead
    (from linuxpackages.net) and never went back to cdrtools.

  3. Re: cdrecord in -current

    On Jul 2, 2:02 am, ljb wrote:
    > But I totally gave up on cdrtools/cdrecord/mkisofs when I switched to the
    > 2.6 kernel in Slackware 11.0. Besides the setup problems (setuid or
    > not), I got tired of the anti-Linux messages from it. Got cdrkit instead
    > (from linuxpackages.net) and never went back to cdrtools.


    I know that other distros have long since moved on to cdrkit, I was
    just trying to figure out if this was still normal behavior in regards
    to cdrtools. I'm assuming the former doesn't have this problem (yeah,
    I don't burn too many CDs/DVDs).

    It also struck me as odd that k3b would be moved to main because it
    doesn't ask to make cdrecord suid root anymore, when in fact the only
    way to make things work is to do exactly that.

    Thanks!


  4. Re: cdrecord in -current

    ljb wrote:
    > spam.lounge@gmail.com wrote:
    >> Hi,
    >>
    >> I recently upgraded to -current and cdrecord has stopped working,
    >> along with all the apps that use it as a backend.
    >>
    >> It bails out with "/usr/bin/cdrecord: Operation not permitted. Cannot
    >> send SCSI cmd via ioctl".
    >>
    >> Setting cdrecord suid root solves the problem, but I don't recall
    >> having to do this in previous slackware versions (I could be wrong,
    >> which would explain why it has stopped working).
    >> ...

    >
    > I've always had to set cdrecord, mkisofs, and readcd setuid root if I
    > wanted to burn and copy CDs as non-root users. (mkisofs needs to be
    > setuid root for working with multisession CDs.)
    >
    > But I totally gave up on cdrtools/cdrecord/mkisofs when I switched to the
    > 2.6 kernel in Slackware 11.0. Besides the setup problems (setuid or
    > not), I got tired of the anti-Linux messages from it. Got cdrkit instead
    > (from linuxpackages.net) and never went back to cdrtools.


    what kind of anti-linux messages?

  5. Re: cdrecord in -current

    kevin.paulus@skynet.be wrote:
    >> ...
    >> But I totally gave up on cdrtools/cdrecord/mkisofs when I switched to the
    >> 2.6 kernel in Slackware 11.0. Besides the setup problems (setuid or
    >> not), I got tired of the anti-Linux messages from it. Got cdrkit instead
    >> (from linuxpackages.net) and never went back to cdrtools.

    >
    > what kind of anti-linux messages?


    (From Slackware 10.2 I think)

    | cdrecord: Warning: Running on Linux-2.6.10
    | cdrecord: There are unsettled issues with Linux-2.5 and newer.
    | cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.
    | Warning: Using badly designed ATAPI via /dev/hd* interface.

    (Solaris??? No thanks.)

    For even more fun reading, search an archive of the linux-kernel mailing
    list for the thread "Request to stop cdrecord's bogus accusations of Linux."

  6. Re: cdrecord in -current

    ljb wrote:
    > kevin.paulus@skynet.be wrote:
    >>> ...
    >>> But I totally gave up on cdrtools/cdrecord/mkisofs when I switched to the
    >>> 2.6 kernel in Slackware 11.0. Besides the setup problems (setuid or
    >>> not), I got tired of the anti-Linux messages from it. Got cdrkit instead
    >>> (from linuxpackages.net) and never went back to cdrtools.

    >> what kind of anti-linux messages?

    >
    > (From Slackware 10.2 I think)
    >
    > | cdrecord: Warning: Running on Linux-2.6.10
    > | cdrecord: There are unsettled issues with Linux-2.5 and newer.
    > | cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.
    > | Warning: Using badly designed ATAPI via /dev/hd* interface.
    >
    > (Solaris??? No thanks.)
    >
    > For even more fun reading, search an archive of the linux-kernel mailing
    > list for the thread "Request to stop cdrecord's bogus accusations of Linux."


    wow that's pretty harsh

  7. Re: cdrecord in -current

    In article <1183335668.181119.156980@o61g2000hsh.googlegroups. com>,
    Grimms wrote:
    >Hi,
    >
    >I recently upgraded to -current and cdrecord has stopped working,
    >along with all the apps that use it as a backend.
    >
    >It bails out with "/usr/bin/cdrecord: Operation not permitted. Cannot
    >send SCSI cmd via ioctl".
    >
    >Setting cdrecord suid root solves the problem, but I don't recall
    >having to do this in previous slackware versions (I could be wrong,
    >which would explain why it has stopped working).


    Your memory is bad ;-)

    Linux always did force cdrecord to have root permissions.

    Some years ago, to the end of the 2.4 series of Linux, someone did intruce
    a serious security bug into Linux that did allow non-root users to open
    a working SCSI pass through device. With Linux-2.6.8.1, you did need
    to be root argain but unfortunetely Linus Torvalds did deliberately
    break the kernel interface at the same time by not fixing the bug that
    caused the problem but rather changing the interface in an incomatible way.
    Note that he did this over night and without any announcement.

    Before the thange, you need to be root when opening the SCSI pass through
    devices and could send SCSI commands as user.

    After the change, you could open the device as user but need root
    permissions in order to send SCSI commands. Even worse: if you are not root
    at that time, some of the commands are allowed but many SCSI commands that
    cdrecord needs are forbidden. As a result, some people who did superficial
    tests believed that cdrecord did not need to be root.

    Torvalds at the time of the change has been asked by many people to remove the
    incompatible change to no avail.

    This was a really bad interface change by Linus Torvalds, as it was
    done during code freeze of cdrtools, less than a week before 2.01-final
    was released. As this Linux kernel bug (an incompatible interface change
    that breaks other programs definitely is a bug) did cause that even a suid
    cdrecord did no longer work and as I could not find a workaround for the
    kernel bug, I decided to add a warning message to cdrecord. This did help
    people to learn that due to a Linux kernel problem, cdrecord did only work
    when _being_ real root.

    A useful workaround for the incompatible kernel interface change was
    found ~ 2 years ago.

    >Browsing through the changelog I see that Pat has moved k3b to main
    >because there's a compile time flag now that disables it asking to set
    >cdrecord suid root.


    If k3b does not ask to install cdrecord suid root, this is a bug.

    I have been in discussions with the k3b people and I am sure that
    the k3b people know about how to correctly call cdrecord (that needs to
    be installed suid root) since about at least 2 years.


    >I remember a few years back all the hoopla around cdrtools with the
    >kernel folks, but I thought this was long since solved, at least it
    >hasn't been an issue I have run across in other distros for a looong
    >time before today with slack.


    Sere above. It is always a bad gesture if someone changes an interface
    so that it breaks other people's software.


    --
    EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    js@cs.tu-berlin.de (uni)
    schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
    URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

  8. Re: cdrecord in -current

    In article <19Yhi.2928$zA4.575@newsread3.news.pas.earthlink.ne t>,
    ljb wrote:

    >I've always had to set cdrecord, mkisofs, and readcd setuid root if I
    >wanted to burn and copy CDs as non-root users. (mkisofs needs to be
    >setuid root for working with multisession CDs.)
    >
    >But I totally gave up on cdrtools/cdrecord/mkisofs when I switched to the
    >2.6 kernel in Slackware 11.0. Besides the setup problems (setuid or
    >not), I got tired of the anti-Linux messages from it. Got cdrkit instead
    >(from linuxpackages.net) and never went back to cdrtools.


    If you like to go with unmaintained software that just hides all messages
    that try to tell the user that a problem exists, wou will end up in
    writing defective CDs.

    Note that unfortunately, many Linux distributions contain old versions
    of cdrtools. Even worse, many of them include bugs written by the distributors.

    The first cdrtools version that did start trying to introduce a
    workaround for the incompatible Linux kernel interface change was 2.01.01a03
    a newer version is recommended.

    "cdrkit" is derived from older source and does not include a clean workaround
    for the problem.

    --
    EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    js@cs.tu-berlin.de (uni)
    schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
    URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

  9. Re: cdrecord in -current

    In article <1183372751.406473.252200@c77g2000hse.googlegroups. com>,
    Grimms wrote:
    >On Jul 2, 2:02 am, ljb wrote:
    >> But I totally gave up on cdrtools/cdrecord/mkisofs when I switched to the
    >> 2.6 kernel in Slackware 11.0. Besides the setup problems (setuid or
    >> not), I got tired of the anti-Linux messages from it. Got cdrkit instead
    >> (from linuxpackages.net) and never went back to cdrtools.

    >
    >I know that other distros have long since moved on to cdrkit, I was
    >just trying to figure out if this was still normal behavior in regards
    >to cdrtools. I'm assuming the former doesn't have this problem (yeah,
    >I don't burn too many CDs/DVDs).


    There are no anti-Linux messages in cdrecord.

    There are however some warnings that tell the user to go back to an
    older version of the Linux kernel in case that something does not work
    and the user is using a Linux kernel that is from the time past the
    incompatible kernel interface change that caused cdrecord to fail to
    run except if it was called by root.


    >It also struck me as odd that k3b would be moved to main because it
    >doesn't ask to make cdrecord suid root anymore, when in fact the only
    >way to make things work is to do exactly that.


    As I mentioned before, this looks like a bug introduced by your distribution.
    The k3b people definitely know that cdrecord needs to run suid root.

    --
    EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    js@cs.tu-berlin.de (uni)
    schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
    URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

  10. Re: cdrecord in -current

    In article <1183372751.406473.252200@c77g2000hse.googlegroups. com>,
    Grimms wrote:

    >I know that other distros have long since moved on to cdrkit, I was
    >just trying to figure out if this was still normal behavior in regards
    >to cdrtools. I'm assuming the former doesn't have this problem (yeah,
    >I don't burn too many CDs/DVDs).


    I did talk with people from RedHat and SuSE at the Linug Tag in Berlin.

    It seems that nobody inside these companies knows _why_ and _how_ this could
    happen.

    The people I was talking to, told me that there was definitely no official
    decision about this change. They did suspect that one of the people who
    is publishing "cdrkit" did find a strange way to convince the single person
    at RedHat resp. SuSe that has the duty to package cdrtools and that this
    person did do the change without asking the RedHat or SuSe distribution
    team for permission.

    It seems to be well known that "cdrkit" did only present speudo changes
    in order to create the impression of active development.

    You should know that even this kind of "activities" did stop ~ 2 months
    ago. After that time, the person who did start the flamewar against
    cdrtools seem to have left Debian.


    Note that "cdrkit" is not the first "fork" from cdrtools.

    In spring 2001, there was another so called "fork". Interestingly, there is a
    great coincidence in observable actions between both "forks".

    - Both "forks" start with claiming that cdrtools are no longer
    free and were using this claim as a justification for the
    need to fork cdrtools.

    - Both people behind the "forks" have not been willing to read
    the documentation for the build system and did rip off the build
    system and replaced it with a self made system that was worse
    than the original with the first step. As a result, both "forks" did
    not work correctly anymore, even on Linux systems if not on x86.
    Support for ther platforms has been broken completely.
    It took both "forks" about half a year to fix the bugs introduced
    by this step.

    - Both "forks" did fall into catatonia after aprox. 9 months.

    - Both "forks" did cause a lot of confusion amongst the users of
    cdrtools and did cause a lot of harm to the project without
    helping anybody.

    People who rely on "cdrkit" should know that they bet on a dead horse.
    During the past 1.5 years, there was a real active development on the
    original cdrtools and the features as wel as usability did increase
    significantly. Also many bugs have been removed (mainly very old bugs from
    mkisofs) that are still present in the "cdrkit" versions of the programs.


    I recommend you to have a look at the recent version

    ftp://ftp.berlios.de/pub/cdrecord/alpha/

    and look at the changelogs.

    --
    EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    js@cs.tu-berlin.de (uni)
    schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
    URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

  11. Re: cdrecord in -current

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    NotDashEscaped: You need GnuPG to verify this message

    On Tue, 3 Jul 2007, Joerg Schilling wrote:
    >
    > and look at the changelogs.


    and still get your anti linux 'use sllloowwaris' spam msgs, no
    thanx, **** off with your bias rhetoric

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)

    iD8DBQFGijKZsWhAmSIQh7MRAmO0AJ9xhsybh43hdxRN7AudbA pWN90m+gCgoKfi
    qygdyaz2lZy0Spia3b2iVpw=
    =9dY8
    -----END PGP SIGNATURE-----

  12. Re: cdrecord in -current

    On 3 Jul 2007 10:46:55 GMT
    js@cs.tu-berlin.de (Joerg Schilling) wrote:

    > In article <1183372751.406473.252200@c77g2000hse.googlegroups. com>,
    > Grimms wrote:
    >
    > >I know that other distros have long since moved on to cdrkit, I was

    ....
    > I recommend you to have a look at the recent version
    >
    > ftp://ftp.berlios.de/pub/cdrecord/alpha/
    >
    > and look at the changelogs.


    Thanks for the interesting comments Joerg, and a pretty good program (kit)!

    --
    Mikhail

  13. Re: cdrecord in -current

    On Sun, 01 Jul 2007 17:21:08 -0700, Grimms wrote:

    >
    > So my question is this: is anyone else running into this problem? And
    > if this is still expected behavior, what is the best way to deal with
    > it? Just set cdrecord suid root? (yuck) I'm already in the cdrom
    > group, so accessing the device itself isn't a problem.
    >
    > Cheers
    >

    I have had best results with k3b as root. I did some sudo tests, but
    IIRC, there were spawned programs which were not being executed sudo. To
    avoid the complication of using sudo, or of starting an entire X session
    for root, I do this (from a regular user account within X):

    $ ssh -X -o ForwardX11Trusted=yes root@localhost
    root@darkstar:~# k3b &

    The common caveats about running commands as root definitely apply with
    this direct method. Be extremely careful if using this method. If you
    would rather fix k3b to work under sudo, it probably can be done. Ubuntu
    has a disabled root account, AIUI; and I assume k3b works with it.

    Note also that encrypting the k3b interface over ssh will consume some
    CPU resources, too.

    --
    Douglas Mayne



  14. Re: cdrecord in -current

    On Jul 3, 10:53 am, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
    > If k3b does not ask to install cdrecord suid root, this is a bug.
    >
    > I have been in discussions with the k3b people and I am sure that
    > the k3b people know about how to correctly call cdrecord (that needs to
    > be installed suid root) since about at least 2 years.


    First of all, thanks for the clarification regarding the status of
    cdrtools and its past issues with Linux.

    As for k3b, this is from the 1.0.1 changelog:

    "New configure check --without-cdrecord-suid-root to disable K3b's
    check for cdrecord permissions. Although not recommended it is
    requested by many distributors."

    I'm assuming this is one of the checks made by k3b when it's opened, I
    vaguely remember the cdrecord suid root warning. Anyway, this isn't
    k3b's default behavior but there is now an option to make it skip that
    check, and thus you'll have to manually change permissions if you're
    using cdrecord on Slackware.

    As for running k3b as root it seems an even worse solution to the
    problem Not only are you calling k3b itself as root, but any helper
    application it uses (and it uses a lot of them) will also run with
    root permissions.

    Thanks for all the input, I hope someone else finds this useful.


  15. Re: cdrecord in -current

    On 2007-07-03, Joerg Schilling wrote:
    > In article <19Yhi.2928$zA4.575@newsread3.news.pas.earthlink.ne t>,
    > ljb wrote:
    >
    >>I've always had to set cdrecord, mkisofs, and readcd setuid root if I
    >>wanted to burn and copy CDs as non-root users. (mkisofs needs to be
    >>setuid root for working with multisession CDs.)
    >>
    >>But I totally gave up on cdrtools/cdrecord/mkisofs when I switched to the
    >>2.6 kernel in Slackware 11.0. Besides the setup problems (setuid or
    >>not), I got tired of the anti-Linux messages from it. Got cdrkit instead
    >>(from linuxpackages.net) and never went back to cdrtools.

    >
    > If you like to go with unmaintained software that just hides all messages
    > that try to tell the user that a problem exists, wou will end up in
    > writing defective CDs.


    > Note that unfortunately, many Linux distributions contain old
    > versions of cdrtools. Even worse, many of them include bugs written
    > by the distributors.


    > The first cdrtools version that did start trying to introduce a
    > workaround for the incompatible Linux kernel interface change was
    > 2.01.01a03 a newer version is recommended.


    > "cdrkit" is derived from older source and does not include a clean
    > workaround for the problem.


    Joerg,

    thanks for taking the time to clarify those points (as well as your
    efforts in providing these tools).

    I see Slack 12.0 has cdrtools-2.01.01a23, and that a27 is considered
    to be the most recent stable version (or so says a29). If a23 works
    on a given person's computer/optical drive, do you think it is worth
    considering upgrading to a27?

    Thanks.
    Jim

  16. Re: cdrecord in -current

    In article ,
    Jim Diamond wrote:

    >thanks for taking the time to clarify those points (as well as your
    >efforts in providing these tools).
    >
    >I see Slack 12.0 has cdrtools-2.01.01a23, and that a27 is considered
    >to be the most recent stable version (or so says a29). If a23 works
    >on a given person's computer/optical drive, do you think it is worth
    >considering upgrading to a27?


    a27 is worth upgrading.

    BTW: I hope that I will be able to get mkisofs off it's current unstable state
    quickly. If it is obvious that mkisofs does not have bugs in old functionality
    and if the Blu Ray extensions (from a29) did not cause problems outside the Blu
    Ray driver, I will create a new "stable" final cdrtools version.

    This version will be taken as a base to complete Blu Ray support and to
    introduce ISO-9660 multi-extent support (the latter gives you the ability to use
    files > 4GB).

    --
    EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    js@cs.tu-berlin.de (uni)
    schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
    URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

+ Reply to Thread