1:54 a.m.
I installed kernel 2.6.8-1.521 today via up2date and k3b stopped working
(doesn't detect burners)
I know that this is a known bug but why does redhat release a kernel
with a known bug as an update?
Wouldn't it be better to wait until this bugs are fixed before releasing
an update?
2:08 a.m.
On Fri, 2004-08-20 at 08:54, dragoran wrote:
I installed kernel 2.6.8-1.521 today via up2date and k3b stopped
working
(doesn't detect burners)
I know that this is a known bug but why does redhat release a kernel
with a known bug as an update?
Wouldn't it be better to wait until this bugs are fixed before releasing
an update?
what is the bug number you filed during the testing phase of this
kernel?
2:44 a.m.
Arjan van de Ven schrieb:
On Fri, 2004-08-20 at 08:54, dragoran wrote:
>I installed kernel 2.6.8-1.521 today via up2date and k3b stopped working
>(doesn't detect burners)
>I know that this is a known bug but why does redhat release a kernel
>with a known bug as an update?
>Wouldn't it be better to wait until this bugs are fixed before releasing
>an update?
>
>
what is the bug number you filed during the testing phase of this
kernel?
I haven't tested the test kernel......
2:45 a.m.
On Fri, Aug 20, 2004 at 09:44:11AM +0200, dragoran wrote:
Arjan van de Ven schrieb:
>On Fri, 2004-08-20 at 08:54, dragoran wrote:
>
>
>>I installed kernel 2.6.8-1.521 today via up2date and k3b stopped working
>>(doesn't detect burners)
>>I know that this is a known bug but why does redhat release a kernel
>>with a known bug as an update?
>>Wouldn't it be better to wait until this bugs are fixed before releasing
>>an update?
>what is the bug number you filed during the testing phase of
this
>kernel?
I haven't tested the test kernel......
ok I thought you had since you say it's a known bug....
Anyway make sure you're not using ide-scsi on the kernel commandline, and
file a bug in bugzilla with dmesg output etc attached...
2:58 a.m.
On Fri, 2004-08-20 at 00:45, Arjan van de Ven wrote:
ok I thought you had since you say it's a known bug....
Yes, it's likely the SCSI command filtering that got stuck into 2.6.8
(there are a couple of threads about this on LKML) in order to prevent
ordinary users (i.e. without CAP_SYS_RAWIO) from sending potentially
dangerous commands to drives (e.g. firmware updates). The list of
allowed commands apparently isn't long enough to let ordinary users
write CDs.
This is the main thread where it's discussed on LKML (linking to a
convenient point where the problem is explained, follow the thread for
more info...)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.2/0091.html
Anyway make sure you're not using ide-scsi on the kernel
commandline, and
file a bug in bugzilla with dmesg output etc attached...
If it broke now, this has nothing to do with it. Probably the command
whitelist needs to be extended a bit. I don't know if anyone has figured
out exactly how much just yet...
/Per
--
Per Bjornsson <perbj(a)stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University
3:09 a.m.
On Fri, 2004-08-20 at 09:58, Per Bjornsson wrote:
On Fri, 2004-08-20 at 00:45, Arjan van de Ven wrote:
> ok I thought you had since you say it's a known bug....
Yes, it's likely the SCSI command filtering that got stuck into 2.6.8
(there are a couple of threads about this on LKML) in order to prevent
ordinary users (i.e. without CAP_SYS_RAWIO) from sending potentially
dangerous commands to drives (e.g. firmware updates). The list of
allowed commands apparently isn't long enough to let ordinary users
write CDs.
ah that thing. Yes that is problematic, especially since some of the
commands used during cd burning appear to belong on the "dangerous"
list...
3:13 a.m.
Arjan van de Ven schrieb:
On Fri, 2004-08-20 at 09:58, Per Bjornsson wrote:
>On Fri, 2004-08-20 at 00:45, Arjan van de Ven wrote:
>
>
>>ok I thought you had since you say it's a known bug....
>>
>>
>Yes, it's likely the SCSI command filtering that got stuck into 2.6.8
>(there are a couple of threads about this on LKML) in order to prevent
>ordinary users (i.e. without CAP_SYS_RAWIO) from sending potentially
>dangerous commands to drives (e.g. firmware updates). The list of
>allowed commands apparently isn't long enough to let ordinary users
>write CDs.
>
>
ah that thing. Yes that is problematic, especially since some of the
commands used during cd burning appear to belong on the "dangerous"
list...
that is what i meant by known bug
5:28 p.m.
Hi Per,
On Fri, 2004-08-20 at 09:58, Per Bjornsson wrote:
Yes, it's likely the SCSI command filtering that got stuck into
2.6.8
(there are a couple of threads about this on LKML) in order to prevent
ordinary users (i.e. without CAP_SYS_RAWIO) from sending potentially
dangerous commands to drives (e.g. firmware updates). The list of
allowed commands apparently isn't long enough to let ordinary users
write CDs.
There also seems to be another issue with writing audio CDs in 2.6.8:
http://kerneltrap.org/node/view/3659
. Note that according to the comments near the bottom the mentioned
patch does *not* entirely fix the problem...
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
10:17 a.m.
>>>> "AvdV" == Arjan van de Ven
<arjanv(a)redhat.com> writes:
AvdV> what is the bug number you filed during the testing phase of
AvdV> this kernel?
That's kind of harsh; I tested the kernel during the testing phase,
but not on the machine used by Mr. Important Professor who wants to
burn CDs but to whom I'm not dumb enough to give root access. K3b
includes a simple file manager and there's a nice little "delete" menu
item. "vmlinuz? I don't need that!" and guess who's reinstalling the
system?
Faced with the choice of giving them root (theoretically allowing them
to destroy the drive and to do other bad things) or backing off to the
previous kernel (theoretically allowing them to destroy the drive), I
think I'll take the latter.
I know the kernel folks are hard at work on this and I'm sure things
will work themselves out soon.
- J<
10:56 a.m.
On Fri, 2004-08-20 at 16:17, Jason L Tibbitts III wrote:
>>>>> "AvdV" == Arjan van de Ven
<arjanv(a)redhat.com> writes:
AvdV> what is the bug number you filed during the testing phase of
AvdV> this kernel?
That's kind of harsh; I tested the kernel during the testing phase,
but not on the machine used by Mr. Important Professor who wants to
burn CDs but to whom I'm not dumb enough to give root access. K3b
sudo perhaps...
11:47 a.m.
On Fri, 2004-08-20 at 10:17 -0500, Jason L Tibbitts III wrote:
>>>>> "AvdV" == Arjan van de Ven
<arjanv(a)redhat.com> writes:
AvdV> what is the bug number you filed during the testing phase of
AvdV> this kernel?
That's kind of harsh; I tested the kernel during the testing phase,
but not on the machine used by Mr. Important Professor who wants to
burn CDs but to whom I'm not dumb enough to give root access. K3b
k3b uses the cdrecord command line tool to do its work, iirc. You don't
need to run k3b as root, just make cdrecord setuid. Which is exactly
how the cdrecord author has always told people to use it. If you want
to limit who can use cdrecord, change it's group and remove execute
permissions for 'others'. Then only people in the group (or root) can
execute cdrecord, and because its setuid root, it'll always work.
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
11:57 a.m.
On Fri, 2004-08-20 at 12:47 -0400, Sean Middleditch wrote:
k3b uses the cdrecord command line tool to do its work, iirc. You
don't
need to run k3b as root, just make cdrecord setuid. Which is exactly
how the cdrecord author has always told people to use it. If you want
to limit who can use cdrecord, change it's group and remove execute
permissions for 'others'. Then only people in the group (or root) can
execute cdrecord, and because its setuid root, it'll always work.
...
which is a bad idea as I can now burn anything on the filesystem. Want
a copy of /etc/shadow to start cracking those passwords? Now you can
get one :)
Jeremy
12:02 p.m.
On Fri, 2004-08-20 at 12:57 -0400, Jeremy Katz wrote:
On Fri, 2004-08-20 at 12:47 -0400, Sean Middleditch wrote:
> k3b uses the cdrecord command line tool to do its work, iirc. You don't
> need to run k3b as root, just make cdrecord setuid. Which is exactly
> how the cdrecord author has always told people to use it. If you want
> to limit who can use cdrecord, change it's group and remove execute
> permissions for 'others'. Then only people in the group (or root) can
> execute cdrecord, and because its setuid root, it'll always work.
...
which is a bad idea as I can now burn anything on the filesystem. Want
a copy of /etc/shadow to start cracking those passwords? Now you can
get one :)
Point. You can then just set the RAWIO capability. I don't know if the
filesystems these days allow setting those; a setuid wrapper that drops
privileges but executes the real cdrecord with the necessary capability
should work, no?
Jeremy
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
12:04 p.m.
On Fri, 2004-08-20 at 18:57, Jeremy Katz wrote:
On Fri, 2004-08-20 at 12:47 -0400, Sean Middleditch wrote:
> k3b uses the cdrecord command line tool to do its work, iirc. You don't
> need to run k3b as root, just make cdrecord setuid. Which is exactly
> how the cdrecord author has always told people to use it. If you want
> to limit who can use cdrecord, change it's group and remove execute
> permissions for 'others'. Then only people in the group (or root) can
> execute cdrecord, and because its setuid root, it'll always work.
...
which is a bad idea as I can now burn anything on the filesystem. Want
a copy of /etc/shadow to start cracking those passwords? Now you can
get one :)
cdrecord drops all it's capabilities except the raw hw one...
12:24 p.m.
New subject: Latest Kernel update appears to be slower
I used up2date to get the latest kernel update after rebuilding to add ntfs
support. It appears to be slower than the previous kernel. Is this just my
imagination or is someone else experiencing the same problem.
2:50 p.m.
On Fri, 2004-08-20 at 12:47, Sean Middleditch wrote:
[snip]
k3b uses the cdrecord command line tool to do its work, iirc. You
don't
need to run k3b as root, just make cdrecord setuid. Which is exactly
how the cdrecord author has always told people to use it.
Which doesn't seem to work, according to my testing, anyhow. Though
he's made a great contribution to FOSS, the author of cdrecord has a few
other *ahem* unique ideas about the way things should be done. *cough*
device numbers *cough*
Methinks we need a more well thought out solution, which, from what I
gather from this week's LWN.net article on it, will be arrived at,
though probably not *this week* or next.
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
6:23 a.m.
On Fri, Aug 20, 2004 at 08:54:09AM +0200, dragoran wrote:
I installed kernel 2.6.8-1.521 today via up2date and k3b stopped
working
(doesn't detect burners)
Run it as root
I know that this is a known bug but why does redhat release a kernel
with a known bug as an update?
Its a security fix not a bug.
6:26 a.m.
Alan Cox schrieb:
On Fri, Aug 20, 2004 at 08:54:09AM +0200, dragoran wrote:
>I installed kernel 2.6.8-1.521 today via up2date and k3b stopped working
>(doesn't detect burners)
>
>
Run it as root
>I know that this is a known bug but why does redhat release a kernel
>with a known bug as an update?
>
>
Its a security fix not a bug.
is there no other solution than running it as root?
8:52 p.m.
dragoran wrote:
I installed kernel 2.6.8-1.521 today via up2date and k3b stopped
working
(doesn't detect burners)
I know that this is a known bug but why does redhat release a kernel
with a known bug as an update?
Wouldn't it be better to wait until this bugs are fixed before releasing
an update?
Well I see this problem too. But nautilus-cd-burner seems to detect my
burner just fine, and so does k3b if I tell it to burn a dvd. I would
guess that in both of these situations growisofs is being used instead
of cdrecord (or dvdrecord). At least nautilus-cd-burner uses it.
Carlos
--
url: http://crodrigues.webhop.net
7224
days inactive
7225
days old
19 comments
12 participants
participants (12)
-
Alan Cox -
Andrew Clayton -
Arjan van de Ven -
Carlos Rodrigues -
dragoran -
Jason L Tibbitts III -
Jeremy Katz -
Leonard den Ottolander -
Otto Haliburton -
Paul Iadonisi -
Per Bjornsson -
Sean Middleditch