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*

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

Nazi.

*Plonk*

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

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*

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 )

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

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

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

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

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

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,

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

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?

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

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.

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

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.

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 )

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