cdrecord as normal user - Slackware

This is a discussion on cdrecord as normal user - Slackware ; Hi, I'm just trying to integrate K3B into XFCE... and discover that I have to jump through burning loops to burn as a normal user. Test: I'm taking some directory and making and ISO of it with mkisofs -J - ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 38

Thread: cdrecord as normal user

  1. cdrecord as normal user

    Hi,

    I'm just trying to integrate K3B into XFCE... and discover that I have to
    jump through burning loops to burn as a normal user.

    Test: I'm taking some directory and making and ISO of it with mkisofs -J -
    r -v -V "test" -o test.iso test/

    And when I try to burn the thing like this as a normal user, I get this:

    Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
    Driver flags : MMC-3 SWABAUDIO BURNFREE FORCESPEED
    Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/
    R96R
    Drive buf size : 1895168 = 1850 KB
    FIFO size : 4194304 = 4096 KB
    Track 01: data 3 MB
    Total size: 3 MB (00:22.48) = 1686 sectors
    Lout start: 4 MB (00:24/36) = 1686 sectors
    cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl

    I googled for about an hour, and found endless discussions about suid
    root and broken kernel interfaces. And my only reaction to this: Jesus.
    Such an important tool as cdrecord, and it's left in an almost unusable
    state. Do they want to compete with Vista's Unusability Experience?

    Does someone have a *practical* suggestion to fix the burn-as-user
    problem? By practical, I don't mean switching back to a 2.4 kernel or <=
    2.6.9, log into XFCE as root or prefer Solaris to Slackware.

    cheers,

    Niki

  2. Re: cdrecord as normal user

    On Sat, 06 Oct 2007 14:29:02 +0000, Niki Kovacs wrote:

    > Such an important tool as cdrecord, and it's left in an almost unusable
    > state. Do they want to compete with Vista's Unusability Experience?


    Troll.

    *Plonk*

  3. Re: cdrecord as normal user

    Le Sat, 06 Oct 2007 14:56:55 +0000, Dave Uhring a √©crit¬*:
    >
    > Troll.
    >
    > *Plonk*


    Nazi.

    *Plonk*


  4. Re: cdrecord as normal user

    Niki Kovacs schreef:
    > Hi,
    >
    > I'm just trying to integrate K3B into XFCE... and discover that I have to
    > jump through burning loops to burn as a normal user.


    I always burn as a normal user. But I let Krb fix the permissions for
    me, and add myself to verious system groups that allow me access to my
    system's hardware components (cdrom, audio, scanner, plugdev, power,
    disk, floppy ... maybe more).

    Eric

  5. Re: cdrecord as normal user

    On Sat, 06 Oct 2007 14:56:55 +0000, Dave Uhring wrote:

    > On Sat, 06 Oct 2007 14:29:02 +0000, Niki Kovacs wrote:
    >
    >> Such an important tool as cdrecord, and it's left in an almost unusable
    >> state. Do they want to compete with Vista's Unusability Experience?

    >
    > Troll.
    >
    > *Plonk*


    Pank.

    *flush*

  6. Re: cdrecord as normal user

    On Sat, 06 Oct 2007 14:29:02 +0000, Niki Kovacs wrote:

    > Hi,
    >
    > I'm just trying to integrate K3B into XFCE... and discover that I have
    > to jump through burning loops to burn as a normal user.
    >
    > Test: I'm taking some directory and making and ISO of it with mkisofs -J
    > - r -v -V "test" -o test.iso test/
    >
    > And when I try to burn the thing like this as a normal user, I get this:
    >
    > Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags :
    > MMC-3 SWABAUDIO BURNFREE FORCESPEED Supported modes: TAO PACKET SAO
    > SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/ R96R
    > Drive buf size : 1895168 = 1850 KB
    > FIFO size : 4194304 = 4096 KB
    > Track 01: data 3 MB
    > Total size: 3 MB (00:22.48) = 1686 sectors Lout start: 4
    > MB (00:24/36) = 1686 sectors cdrecord: Operation not permitted. Cannot
    > send SCSI cmd via ioctl
    >
    > I googled for about an hour, and found endless discussions about suid
    > root and broken kernel interfaces. And my only reaction to this: Jesus.
    > Such an important tool as cdrecord, and it's left in an almost unusable
    > state. Do they want to compete with Vista's Unusability Experience?
    >
    > Does someone have a *practical* suggestion to fix the burn-as-user
    > problem? By practical, I don't mean switching back to a 2.4 kernel or <=
    > 2.6.9, log into XFCE as root


    add the user to the 'burning' group and send the good parole in cdrecord:
    # chmod 2710 /usr/bin/cdrecord

    You may have access/perf issues if you don't care of the correct
    interface-device you should use, Joerg included precise tools to
    check what could be the best bet:

    # cdrecord -scanbus
    # cdrecord dev=help

    And you'll adore (obviously, put your correct dev ref in this command):
    # cdrecord dev=1001,0,0 -checkdrive

    > or prefer Solaris to Slackware.


    Ggggolleez, switching to a b0rken Unix (alas) in order to cure a
    semantic problem inherent to some members of the lkml is
    a bit over the top )

  7. Re: cdrecord as normal user

    On 2007-10-06, Niki Kovacs wrote:
    > Hi,
    >
    > I'm just trying to integrate K3B into XFCE... and discover that I have to
    > jump through burning loops to burn as a normal user.
    >
    > And when I try to burn the thing like this as a normal user, I get this:
    > cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl


    What about udev? You can have permission to write for this device.

    Never tried since i burn as root from console

    this is from my device:
    BUS=="scsi", KERNEL=="sr0", SYSFS{vendor}=="_NEC ", \
    SYSFS{model}=="DVD_RW ND-4570A ", NAME="%k", SYMLINK+="usb/nec", \
    RUN+="/bin/sh -c 'chgrp korging /dev/sr0'"

    So, no suid and stuff
    --
    Please excuse my english writing!
    Slackware 12
    Knowledge report: One and 1/2 year, still plenty to learn

  8. Re: cdrecord as normal user

    On Sat, 06 Oct 2007 16:32:05 +0000, korgman wrote:

    > On 2007-10-06, Niki Kovacs wrote:
    >> Hi,
    >>
    >> I'm just trying to integrate K3B into XFCE... and discover that I have
    >> to jump through burning loops to burn as a normal user.
    >>
    >> And when I try to burn the thing like this as a normal user, I get
    >> this: cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl

    >
    > What about udev? You can have permission to write for this device.
    >
    > Never tried since i burn as root from console


    So as if someone passing by dropped an alias and trixxxed
    some stuff in usual functions? You're way much cooler
    than I am although even Poutine had to tell me to stop
    looking at him this way whle I just was having a flash of a nap ;->

    >
    > this is from my device:
    > BUS=="scsi", KERNEL=="sr0", SYSFS{vendor}=="_NEC ", \
    > SYSFS{model}=="DVD_RW ND-4570A ", NAME="%k", SYMLINK+="usb/nec", \
    > RUN+="/bin/sh -c 'chgrp korging /dev/sr0'"
    >
    > So, no suid and stuff


    That'd be OK for a single user set-up, but I soomehow doubt that's
    what Niki wanted to configure!?

  9. Re: cdrecord as normal user

    On Sat, 6 Oct 2007, Niki Kovacs wrote:


    because of jorgs anti-linux traits, there are free breakaways of this
    project that work just as well, and some say better, the debian team have
    done one such project (and its in source for all to use), jorg believes
    only in two things, scsi and solaris, because he only knows scsi
    well, he tries tell linux develop team they are clueless because the
    2.6 kernel doesnt use scsi hooks for it like 2.4 used to, youll get used
    to jorgs rhetoric after a while, most just ignore and laugh at him.

    cdrtools is not, never has been, and never will be, the only cd/dvd
    burning software

    --

    Cheers
    Res


  10. Re: cdrecord as normal user

    On 2007-10-06, Eric Hameleers wrote:
    > Niki Kovacs schreef:
    >> Hi,
    >>
    >> I'm just trying to integrate K3B into XFCE... and discover that I have to
    >> jump through burning loops to burn as a normal user.

    >
    > I always burn as a normal user. But I let Krb fix the permissions for
    > me, and add myself to verious system groups that allow me access to my
    > system's hardware components (cdrom, audio, scanner, plugdev, power,
    > disk, floppy ... maybe more).



    Note: most of this is to Niki as opposed to Eric... :-)

    I don't even bother with letting k3b do things - this accomplishes
    the same result:

    $ ls -l $(which cdrecord)
    -rwsr-x--- 1 root cdrom 338K 2007-02-18 19:42 /usr/bin/cdrecord*

    Someone mentioned a "burning" group, and that's what k3b suggests,
    although it does allow you to specify a different group name.
    I don't see much need to worry about cdrecord being suid,
    especially in this configuration, as only members of 'cdrom'
    group can use it anyway.

    RW

  11. Re: cdrecord as normal user

    Niki Kovacs wrote:
    > Hi,


    > I'm just trying to integrate K3B into XFCE... and discover that I have to
    > jump through burning loops to burn as a normal user.


    > Test: I'm taking some directory and making and ISO of it with mkisofs -J -
    > r -v -V "test" -o test.iso test/


    > And when I try to burn the thing like this as a normal user, I get this:


    [snip]

    > I googled for about an hour, and found endless discussions about suid
    > root and broken kernel interfaces. And my only reaction to this: Jesus.
    > Such an important tool as cdrecord, and it's left in an almost unusable
    > state. Do they want to compete with Vista's Unusability Experience?


    Linux is secure. I have accepted this nuisance as a necessary, and I
    have found a way to deal with it. (See below.)

    > Does someone have a *practical* suggestion to fix the burn-as-user
    > problem? By practical, I don't mean switching back to a 2.4 kernel or <=
    > 2.6.9, log into XFCE as root or prefer Solaris to Slackware.


    > cheers,


    > Niki


    Niki,

    I use sudo and some bash shell scripting to solve this problem. What I
    do goes like this (this is from my project called "An Application of
    SAM for GLS"). I've compressed and edited the steps to make them more
    suited to your needs:

    In short, this is what I do to burn file image.iso to a cd. I do this
    as a regular user. File image.iso is in the current directory:

    sudo k_burnit image

    To use this you will need files k_burnit and burnit in /usr/local/bin
    or other location in your PATH. They should be owned by root and not
    readable or executable by anyone but root.

    I put mine in /opt/SAMM and changed my PATH to include this dir. Here
    is a listing:

    -rwx------ 1 root root 433 2007-10-06 21:09 /opt/SAMM/burnit
    -rwx------ 1 root root 33 2007-10-06 21:09 /opt/SAMM/k_burnit

    You will also need file prep and directory temp. They should go in the
    home directory of each user of these tools. Here is a listing:

    -rwx------ 1 joe users 457 2007-10-06 21:15 /home/joe/prep
    drwxr-xr-x 2 joe users 4096 2007-10-06 21:06 /home/joe/temp/

    And you will need to put k_burnit in the sudoers file for each user of
    these tools. Here is an excerpt from my sudoer file:

    joe airlink9=/opt/SAMM/k_burnit

    You need root authority (through sudo) to run k_burnit, but anything
    invoked inside of k_burnit runs also with root authority. The leading
    "k_" means "kick", as in "kick start" or "kick off".

    Script k_burnit starts burnit indirectly through script prep. Script
    prep is meant to be general purpose. You could make many pairs of
    scripts (like the k_burnit/burnit pair). Each k_ file would invoke
    it's partner through prep.

    Script prep is used to do two things. It exports variables needed by
    this method. And it builds and runs script elusive. Script elusive is
    used as a way to accomplish what is needed here. You may be able do
    this in other ways, but this is what has worked for me in my SAM
    system.

    Script elusive does the final invocation. In this case it runs burnit.

    Here are scripts k_burnit, burnit and prep:


    k_burnit:

    #!/bin/sh
    ~/prep burnit $*


    burnit:

    #!/bin/sh

    #burnit Burns $1.iso to the cd at
    # speed=$cd_speed and dev=$cd_dev and with option(s) $2.


    #You will need to export cd_dev and cd_speed first
    #to meet your needs. Use "cdrecord -scanbus"
    #to see what three digits to use for cd_dev.
    #E.g., "export cd_dev=1,0,0"

    #Refer to your own notes and knowledge for cd_speed.

    cdrecord -v speed=$cd_speed dev=$cd_dev $2 -data $1.iso


    prep:

    #!/bin/sh

    # Do your exporting here.
    export temp_dir=$HOME/temp
    export cd_dev=1,0,0
    export cd_speed=4

    # This wipes file elusive and sets its permissions.
    echo "#" > $temp_dir/elusive
    chmod 644 $temp_dir/elusive

    # You may need something from your .bashrc.
    if [ -r $HOME/.bashrc ]; then
    echo "source $HOME/.bashrc" >> $temp_dir/elusive
    fi

    # This puts prep's arguments in file elusive.
    echo "$*" >> $temp_dir/elusive

    bash -c "source $temp_dir/elusive"


    I hope this helps.

    -Joe

  12. Re: cdrecord as normal user

    Niki Kovacs wrote:

    > I googled for about an hour, and found endless discussions about suid
    > root and broken kernel interfaces. And my only reaction to this: Jesus.
    > Such an important tool as cdrecord, and it's left in an almost unusable
    > state. Do they want to compete with Vista's Unusability Experience?


    Situations like this are the down side of the open source development model,
    I guess.

    > Does someone have a *practical* suggestion to fix the burn-as-user
    > problem? By practical, I don't mean switching back to a 2.4 kernel or <=
    > 2.6.9, log into XFCE as root or prefer Solaris to Slackware.


    Not sure how practical my solution is, but since I compile my own kernels I
    always add the patch below to disable the SCSI authorization check. On a
    private workstation I don't see this as a security risk. Hell, we lived
    without this check for the first 16 years of Linux.

    Martinus

    --- block/scsi_ioctl.c *2007-02-04 19:44:54.000000000 +0100
    +++ block/scsi_ioctl.c *2007-05-28 23:49:49.000000000 +0200
    @@ -114,6 +114,7 @@
    *
    *static int verify_command(struct file *file, unsigned char *cmd)
    *{
    +#if 0
    * * * * static unsigned char cmd_type[256] = {
    *
    * * * * * * * * /* Basic read-only commands */
    @@ -218,6 +219,9 @@
    *
    * * * * /* Otherwise fail it with an "Operation not permitted" */
    * * * * return -EPERM;
    +#else
    + * * * return 0;
    +#endif
    *}
    *
    *static int sg_io(struct file *file, request_queue_t *q,


  13. Re: cdrecord as normal user

    Le Sun, 07 Oct 2007 06:04:05 +0000, Joseph H. Rosevear a √©crit¬*:
    > prep:
    >
    > #!/bin/sh
    >
    > # Do your exporting here.
    > export temp_dir=$HOME/temp
    > export cd_dev=1,0,0
    > export cd_speed=4
    >
    > # This wipes file elusive and sets its permissions. echo "#" >
    > $temp_dir/elusive
    > chmod 644 $temp_dir/elusive
    >
    > # You may need something from your .bashrc. if [ -r $HOME/.bashrc ];
    > then
    > echo "source $HOME/.bashrc" >> $temp_dir/elusive
    > fi
    >
    > # This puts prep's arguments in file elusive. echo "$*" >>
    > $temp_dir/elusive
    >
    > bash -c "source $temp_dir/elusive"
    >
    >
    > I hope this helps.


    Well, yes and no. I got your point. But the thing is: this is for
    building a nOOb-friendly desktop, one application per task, and if
    possible, the most user-friendly application per task. Whereas I mainly
    use plain mkisofs and cdrecord for burning, I can't expect my users here
    (library and town hall employess, some of whom barely know how to handle
    a mouse) to launch shell scripts.

    cheers,

    Niki

  14. Re: cdrecord as normal user

    On Sat, 06 Oct 2007 14:29:02 +0000, Niki Kovacs wrote:

    > I googled for about an hour, and found endless discussions about suid
    > root and broken kernel interfaces. And my only reaction to this: Jesus.
    > Such an important tool as cdrecord, and it's left in an almost unusable
    > state. Do they want to compete with Vista's Unusability Experience?


    I'm surprised that Joerg Schilling hasn't been by to answer this one, he
    seems to do what Kibo used to: grep the spool for all instances of
    cdrecord.

    He does normally say (I reserve the right to claim that I haven't
    understood anything that he said :-) that cdrecord is meant to be run as
    root.

    > Does someone have a *practical* suggestion to fix the burn-as-user
    > problem? By practical, I don't mean switching back to a 2.4 kernel or <=
    > 2.6.9, log into XFCE as root or prefer Solaris to Slackware.


    Sudo?

  15. Re: cdrecord as normal user

    On Sat, 06 Oct 2007 16:12:27 +0000, loki harfagr wrote:

    >> or prefer Solaris to Slackware.

    >
    > Ggggolleez, switching to a b0rken Unix (alas) in order to cure a
    > semantic problem inherent to some members of the lkml is
    > a bit over the top )


    Well, quite a few bits of cdrecord are problematic in *BSD as well (try
    cdrecord -scanbus under OpenBSD sometime) and that can't be blamed on the
    members of the lkml....

  16. Re: cdrecord as normal user

    On Sun, 07 Oct 2007 07:20:38 +1000, Res wrote:

    > because of jorgs anti-linux traits, there are free breakaways of this
    > project that work just as well, and some say better, the debian team have
    > done one such project (and its in source for all to use)


    I use those tools under Debian, and while they can work, they are not as
    mature or powerful as cdrecord (even taking its flaws into account).

    For example, no DAO mode yet. But it's early days.

  17. Re: cdrecord as normal user

    Niki Kovacs wrote:
    > Le Sun, 07 Oct 2007 06:04:05 +0000, Joseph H. Rosevear a ?crit?:
    >> prep:
    >>
    >> #!/bin/sh
    >>
    >> # Do your exporting here.
    >> export temp_dir=$HOME/temp
    >> export cd_dev=1,0,0
    >> export cd_speed=4


    [snip]

    >> I hope this helps.

    >
    > Well, yes and no. I got your point. But the thing is: this is for
    > building a nOOb-friendly desktop, one application per task, and if
    > possible, the most user-friendly application per task. Whereas I mainly
    > use plain mkisofs and cdrecord for burning, I can't expect my users here
    > (library and town hall employess, some of whom barely know how to handle
    > a mouse) to launch shell scripts.
    >
    > cheers,
    >
    > Niki


    Niki,

    Wow. Sounds like you have an honorable task before you. I often wish I
    had users. I write tools for my own use. I have tried to show my
    peers (teachers at public school for children aged 5-11 years) the
    benefits of automating tasks through scripting, but so far it has been
    a rare thing to even have an audience for the subject.

    Do you think your users could handle a two step process? It would go
    like this:

    1. Copy the files and folders to be burned to a special directory
    (maybe $HOME/burn).

    2. Click a button in the KDE panel.

    I made a button in a KDE panel to see if it would work. I did this:

    right click on panel
    panel menu
    add application to panel
    add non-KDE application
    Button title: burn-it
    Description: burn the files in $HOME/burn to a CD
    Executable: sudo
    Arguments: k_burnit2
    Run in a window: X

    Then I made k_burnit2 and burnit2 in /usr/local/bin. Directory $HOME/temp and
    script $HOME/prep are the same as before. I also made directory
    $HOME/burn and I put some files in it.

    I updated sudoers by use of visudo (as root) and added this line:

    joe max=/usr/local/bin/k_burnit2

    Then I put a blank CD in the drive and clicked on the new icon in the
    KDE panel. It prompted me for a password (user password, not root) and
    burned the contents of $HOME/burn to the CD.

    Here are k_burnit2 and burnit2:

    k_burnit2:

    #!/bin/sh
    ~/prep burnit2 $*


    burnit2:

    #!/bin/sh

    #burnit2 No arguments. Burns the contents of $HOME/burn to a CD.
    # at speed=$cd_speed and dev=$cd_dev

    # make the image
    cd $HOME/burn
    rm ../image.iso
    mkisofs -r -o ../image.iso ./

    #You will need to export cd_dev and cd_speed first
    #to meet your needs. Use "cdrecord -scanbus"
    #to see what three digits to use for cd_dev.
    #E.g., "export cd_dev=1,0,0"

    #Refer to your own notes and knowledge for cd_speed.

    cdrecord -v speed=$cd_speed dev=$cd_dev $2 -data ../image.iso

    What will your users be burning? Do you think they could handle
    copying files/folders to a directory before burning them to a CD?

    I don't know how else to do this. I tried K3b, but it wouldn't work
    for me. I did this test (above) in Slackware 12.0, by the way.

    -Joe

  18. Re: cdrecord as normal user

    Joseph H. Rosevear wrote:

    > I use sudo and some bash shell scripting to solve this problem. What I
    > do goes like this (this is from my project called "An Application of
    > SAM for GLS"). I've compressed and edited the steps to make them more
    > suited to your needs:
    >
    > In short, this is what I do to burn file image.iso to a cd. I do this
    > as a regular user. File image.iso is in the current directory:
    >
    > sudo k_burnit image
    >
    > To use this you will need files k_burnit and burnit in /usr/local/bin
    > or other location in your PATH. They should be owned by root and not
    > readable or executable by anyone but root.
    >
    > I put mine in /opt/SAMM and changed my PATH to include this dir. Here
    > is a listing:
    >
    > -rwx------ 1 root root 433 2007-10-06 21:09 /opt/SAMM/burnit
    > -rwx------ 1 root root 33 2007-10-06 21:09 /opt/SAMM/k_burnit
    >
    > You will also need file prep and directory temp. They should go in the
    > home directory of each user of these tools. Here is a listing:
    >
    > -rwx------ 1 joe users 457 2007-10-06 21:15 /home/joe/prep
    > drwxr-xr-x 2 joe users 4096 2007-10-06 21:06 /home/joe/temp/
    >
    > And you will need to put k_burnit in the sudoers file for each user of
    > these tools. Here is an excerpt from my sudoer file:
    >
    > joe airlink9=/opt/SAMM/k_burnit
    >
    > You need root authority (through sudo) to run k_burnit, but anything
    > invoked inside of k_burnit runs also with root authority. The leading
    > "k_" means "kick", as in "kick start" or "kick off".
    >
    > Script k_burnit starts burnit indirectly through script prep. Script
    > prep is meant to be general purpose. You could make many pairs of
    > scripts (like the k_burnit/burnit pair). Each k_ file would invoke
    > it's partner through prep.
    >
    > Script prep is used to do two things. It exports variables needed by
    > this method. And it builds and runs script elusive. Script elusive is
    > used as a way to accomplish what is needed here. You may be able do
    > this in other ways, but this is what has worked for me in my SAM
    > system.
    >
    > Script elusive does the final invocation. In this case it runs burnit.
    >
    > Here are scripts k_burnit, burnit and prep:
    >
    >
    > k_burnit:
    >
    > #!/bin/sh
    > ~/prep burnit $*
    >
    >
    > burnit:
    >
    > #!/bin/sh
    >
    > #burnit Burns $1.iso to the cd at
    > # speed=$cd_speed and dev=$cd_dev and with option(s) $2.
    >
    >
    > #You will need to export cd_dev and cd_speed first
    > #to meet your needs. Use "cdrecord -scanbus"
    > #to see what three digits to use for cd_dev.
    > #E.g., "export cd_dev=1,0,0"
    >
    > #Refer to your own notes and knowledge for cd_speed.
    >
    > cdrecord -v speed=$cd_speed dev=$cd_dev $2 -data $1.iso
    >
    >
    > prep:
    >
    > #!/bin/sh
    >
    > # Do your exporting here.
    > export temp_dir=$HOME/temp
    > export cd_dev=1,0,0
    > export cd_speed=4
    >
    > # This wipes file elusive and sets its permissions.
    > echo "#" > $temp_dir/elusive
    > chmod 644 $temp_dir/elusive
    >
    > # You may need something from your .bashrc.
    > if [ -r $HOME/.bashrc ]; then
    > echo "source $HOME/.bashrc" >> $temp_dir/elusive
    > fi
    >
    > # This puts prep's arguments in file elusive.
    > echo "$*" >> $temp_dir/elusive
    >
    > bash -c "source $temp_dir/elusive"
    >
    >
    > I hope this helps.


    I see three *big* security issues with this.
    First you run the user owned script ~/prep with root privilege. A
    user can simply put any command (s)he likes to run as root in that
    script.
    Second using this scripts you'll run the user's $HOME/.bashrc
    with root privilege. So a user can also put any command (s)he likes
    in .bashrc and run that command as root.
    Third you trust the command line supplied by the user. This is yet
    an other way for the user to specify any command to be run as root.
    A user could call the k_burnit script for instance as:
    sudo k_burnit 'blah;/bin/bash'
    to get a root shell as k_burnit will run in this case:
    ~/prep burnit blah;/bin/bash

    Regards,

    Kees.

    --
    Kees Theunissen.

  19. Re: cdrecord as normal user

    Sun, 07 Oct 2007 03:17:21 +0000, Robby Workman did cat¬*:

    > On 2007-10-06, Eric Hameleers wrote:
    >> Niki Kovacs schreef:
    >>> Hi,
    >>>
    >>> I'm just trying to integrate K3B into XFCE... and discover that I have
    >>> to jump through burning loops to burn as a normal user.

    >>
    >> I always burn as a normal user. But I let Krb fix the permissions for
    >> me, and add myself to verious system groups that allow me access to my
    >> system's hardware components (cdrom, audio, scanner, plugdev, power,
    >> disk, floppy ... maybe more).

    >
    >
    > Note: most of this is to Niki as opposed to Eric... :-)
    >
    > I don't even bother with letting k3b do things - this accomplishes the
    > same result:
    >
    > $ ls -l $(which cdrecord)
    > -rwsr-x--- 1 root cdrom 338K 2007-02-18 19:42 /usr/bin/cdrecord*
    >
    > Someone mentioned a "burning" group, and that's what k3b suggests,
    > although it does allow you to specify a different group name. I don't
    > see much need to worry about cdrecord being suid, especially in this
    > configuration, as only members of 'cdrom' group can use it anyway.


    I agree on this too, as a matter of fact I used to use the
    group 'audio' to this effect, as I was accustomed to differenciate people
    who could use the CD from people that could use precious devices like
    RTC sound, so I here quoted the 'burning' group as a class whatever its real name.

    Later on, seeing that the default usage in K3B (an application that
    started to be seen everywhere) was the group "burning" I changed my 'burning'
    group (class) to the "burning" one, that implied less calls in the middle of the
    weekend about what to answer to the funny questions that K3B asked about
    a group that wasn't here )

  20. Re: cdrecord as normal user

    Le Mon, 08 Oct 2007 02:47:54 +0000, Joseph Rosevear a √©crit¬*:

    > Wow. Sounds like you have an honorable task before you. I often wish I
    > had users.


    Well, more often than not, I wish I had none. There's that old lady,
    Madame Bancel. She's a retired school teacher, helping out in the public
    library every wednesday morning. After a few hours of right-and-left
    single-and-double-clicking on every conceivable and inconceivable part of
    the screen, my carefully configured XFCE desktop looks like the Hilton
    Suite after a party with Metallica and two dozens of groupies.

    cheers,

    Niki

+ Reply to Thread
Page 1 of 2 1 2 LastLast