FC6 Test2 was delayed because of a broken xen (which wasn't bad at all!= but I think this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179862 is a more serve issue its a regression introduced in FC5 (I am still using the FC4 packages) and is still unfixed. User can't burn cds, when using some burners, expect when they do it as root. which is no solution, because of security issues and problems when using guis. We should fix this issue before realsing FC6 (or even test3) since this hits many users and cdburning is a task that every user will do from time to time (not like setting up a vm). So please do *not* release FC6 Test3 until this one is fixed!
So please do *not* release FC6 Test3 until this one is fixed!
And also the annoying pc speaker beep that showed up in the last week or two.
-Steve
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Steve G wrote:
So please do *not* release FC6 Test3 until this one is fixed!
And also the annoying pc speaker beep that showed up in the last week or two.
-Steve
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
bug number?
Blacklist the module.
echo "blacklist pcspkr" >> /etc/modprob.d/blacklist
Honestly, do we have to do that? Something changed its behavior and I don't think every person that downloads fedora should have to blacklist it. I heard a rumor that maybe udev is responsible. Is there a change in it that would have done this?
-Steve
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Once upon a time, Steve G linux_4ever@yahoo.com said:
Blacklist the module.
echo "blacklist pcspkr" >> /etc/modprob.d/blacklist
Honestly, do we have to do that? Something changed its behavior and I don't think every person that downloads fedora should have to blacklist it. I heard a rumor that maybe udev is responsible. Is there a change in it that would have done this?
Honestly, the PC speaker has been broken for a couple of years in Fedora because the module didn't get loaded automatically (like virtually every other hardware module). If it is there, it should be loaded unless the module is blacklisted to block it.
Chris Adams wrote:
Once upon a time, Steve G linux_4ever@yahoo.com said:
Blacklist the module.
echo "blacklist pcspkr" >> /etc/modprob.d/blacklist
Honestly, do we have to do that? Something changed its behavior and I don't think every person that downloads fedora should have to blacklist it. I heard a rumor that maybe udev is responsible. Is there a change in it that would have done this?
Honestly, the PC speaker has been broken for a couple of years in Fedora because the module didn't get loaded automatically (like virtually every other hardware module). If it is there, it should be loaded unless the module is blacklisted to block it.
Related bug report ->
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160172
Rahul
On Friday 28 July 2006 14:52, Chris Adams wrote:
Honestly, the PC speaker has been broken for a couple of years in Fedora because the module didn't get loaded automatically (like virtually every other hardware module). If it is there, it should be loaded unless the module is blacklisted to block it.
Unfortunately because this seems to effect only plextor users, and there are some work arounds for it, I don't think this would classify as a blocker bug. But I'd sure like to see a PROPER fix for this (upsream), I just don't know if it can be done in time.
On Friday 28 July 2006 17:54, Jesse Keating wrote:
On Friday 28 July 2006 14:52, Chris Adams wrote:
Honestly, the PC speaker has been broken for a couple of years in Fedora because the module didn't get loaded automatically (like virtually every other hardware module). If it is there, it should be loaded unless the module is blacklisted to block it.
Unfortunately because this seems to effect only plextor users, and there are some work arounds for it, I don't think this would classify as a blocker bug. But I'd sure like to see a PROPER fix for this (upsream), I just don't know if it can be done in time.
Heh, disregard this, I quoted the wrong email (:
On Fri, 2006-07-28 at 11:50 -0700, Steve G wrote:
Honestly, do we have to do that? Something changed its behavior and I don't think every person that downloads fedora should have to blacklist it. I heard a rumor that maybe udev is responsible. Is there a change in it that would have done this?
Funny, I thought it was an odd change in behavior when my PC beeper stopped working way back in FC2...
AFAIK it happened simply because the PC speaker driver was modularized in kernel 2.6 and nothing was put into place to get the module loaded. It appears most people didn't notice or care.
Steve G wrote :
Blacklist the module.
echo "blacklist pcspkr" >> /etc/modprob.d/blacklist
Honestly, do we have to do that? Something changed its behavior and I don't think every person that downloads fedora should have to blacklist it. I heard a rumor that maybe udev is responsible. Is there a change in it that would have done this?
Oh, it's not just me!
I've been annoying everyone in the office for the last few weeks : GDM beeps at startup, many remote servers I connect to through ssh still have their terminal bell on (and disabling the local one in gnome-terminal doesn't take care of them), and I now realized for the first time that minicom plays some kind of music when it finishes xmodem transfers!!! I'm sure co-workers thought I caught a virus from the 80's of that I was playing some old DOS-based game...
I really thought this was an ALSA bug, because I have a "PC Speak" mixer available, which I've always muted just in case. Shouldn't it actually mute the PC speaker or is it something totally different?
Matthias
Le lundi 31 juillet 2006 à 11:22 +0200, Matthias Saou a écrit :
Steve G wrote :
Blacklist the module.
echo "blacklist pcspkr" >> /etc/modprob.d/blacklist
Honestly, do we have to do that? Something changed its behavior and I don't think every person that downloads fedora should have to blacklist it. I heard a rumor that maybe udev is responsible. Is there a change in it that would have done this?
Oh, it's not just me!
OTOH I am happy to have my speaker working again :)
On 7/31/06, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le lundi 31 juillet 2006 à 11:22 +0200, Matthias Saou a écrit :
Steve G wrote :
Is the need here is for a feature request for system-config-soundcard to have a turn on/off speaker in it... for the user who needs it off/on?
Is the need here is for a feature request for system-config-soundcard to have a turn on/off speaker in it... for the user who needs it off/on?
I'd say so. There are just to many yappy programs. Do you really need to hear a beep when doing tab completion?
-Steve
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Mon, Jul 31, 2006 at 03:37:48PM -0700, Steve G wrote:
Is the need here is for a feature request for system-config-soundcard to have a turn on/off speaker in it... for the user who needs it off/on?
I'd say so. There are just to many yappy programs. Do you really need to hear a beep when doing tab completion?
Turn show-all-if-ambiguous on.
On 8/1/06, Steve G linux_4ever@yahoo.com wrote:
I'd say so. There are just to many yappy programs. Do you really need to hear a beep when doing tab completion?
I agree. Having a beep when something finishes is good, or for example when you ask for screen to beep when something changes, but the rest of the time it is very annoying and I usually disconnect the speaker at the motherboard. It would be cool if there was a way to allow beeps on a per-application level.
n0dalus.
On Mon, Jul 31, 2006 at 03:37:48PM -0700, Steve G wrote:
Is the need here is for a feature request for system-config-soundcard to have a turn on/off speaker in it... for the user who needs it off/on?
I'd say so. There are just to many yappy programs. Do you really need to hear a beep when doing tab completion?
Try these:
.inputrc: set prefer-visible-bell #set bell-style visible set bell-style none
.tcshrc: set visiblebell set matchbeep = nomatch
.emacs: (setq visible-bell t)
Chuck Anderson wrote :
On Mon, Jul 31, 2006 at 03:37:48PM -0700, Steve G wrote:
Is the need here is for a feature request for system-config-soundcard to have a turn on/off speaker in it... for the user who needs it off/on?
I'd say so. There are just to many yappy programs. Do you really need to hear a beep when doing tab completion?
Try these:
.inputrc: set prefer-visible-bell #set bell-style visible set bell-style none
.tcshrc: set visiblebell set matchbeep = nomatch
.emacs: (setq visible-bell t)
GDM will still beep on startup by default, won't it?
And this will only affect local shells, not remote shells accessed through ssh, right?
I'm part of those who live fine without the working internal speaker. I'd simply disconnect it if it was possible, unfortunately this is a laptop.
I now know that I can simply blacklist the kernel module, but I'd really prefer a more user-friendly way of achieving the same thing, like for instance by just muting the PC Speaker ALSA mixer channel...
Matthias
I like to use something like "xset b 50 100 5" for a nice subtle click instead of an obnoxious beep. Or you can just "xset b off". On the text console there's "setterm -blength"...
An old topic, but felt the need to get back to it. I did this (with the spelling correction) and my pcspkr module still loads every time. Do I need to set something up to tell modprobe to actually use the blacklist?
Thanks! Skadz
On 7/28/06, Jesse Keating jkeating@redhat.com wrote:
On Friday 28 July 2006 13:34, Steve G wrote:
And also the annoying pc speaker beep that showed up in the last week or two.
Blacklist the module.
echo "blacklist pcspkr" >> /etc/modprob.d/blacklist
-- Jesse Keating Release Engineer: Fedora
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Friday 28 July 2006 09:43, dragoran wrote:
We should fix this issue before realsing FC6 (or even test3) since this hits many users and cdburning is a task that every user will do from time to time (not like setting up a vm). So please do *not* release FC6 Test3 until this one is fixed!
Unfortunately because this seems to effect only plextor users, and there are some work arounds for it, I don't think this would classify as a blocker bug. But I'd sure like to see a PROPER fix for this (upsream), I just don't know if it can be done in time.
fre, 28 07 2006 kl. 17:55 -0400, skrev Jesse Keating:
On Friday 28 July 2006 09:43, dragoran wrote:
We should fix this issue before realsing FC6 (or even test3) since this hits many users and cdburning is a task that every user will do from time to time (not like setting up a vm). So please do *not* release FC6 Test3 until this one is fixed!
Unfortunately because this seems to effect only plextor users, and there are some work arounds for it, I don't think this would classify as a blocker bug. But I'd sure like to see a PROPER fix for this (upsream), I just don't know if it can be done in time.
It does not only affect Plextor users, I count TEAC as well and I have heard NEC also suffers. I also know of a number of users with unnamed hardware who has hit this problem.
This is a regression, it worked in FC4 and it was rejected for FC5 - I was under the impression that it would indeed be a target for fixing in FC6.
- David Nielsen
On Friday 28 July 2006 20:21, David Nielsen wrote:
It does not only affect Plextor users, I count TEAC as well and I have heard NEC also suffers. I also know of a number of users with unnamed hardware who has hit this problem.
This is a regression, it worked in FC4 and it was rejected for FC5 - I was under the impression that it would indeed be a target for fixing in FC6.
Ah, the bug report seemed filled w/ plextor users. I have a NEC at work and it works fine.
The root of the problem may in fact be in the kernel, and we can't very well ship the FC4 kernel in FC6.
Can you state, without a doubt, what the exact problem is and an exact way to fix it?
fre, 28 07 2006 kl. 20:26 -0400, skrev Jesse Keating:
On Friday 28 July 2006 20:21, David Nielsen wrote:
It does not only affect Plextor users, I count TEAC as well and I have heard NEC also suffers. I also know of a number of users with unnamed hardware who has hit this problem.
This is a regression, it worked in FC4 and it was rejected for FC5 - I was under the impression that it would indeed be a target for fixing in FC6.
Ah, the bug report seemed filled w/ plextor users. I have a NEC at work and it works fine.
I count at least one TEAC user in the bug, I have a TEAC SCSI drive lying around if I can find it I'll test to confirm. Regardless Plextor is a well known brand which has seen a lot of deployment.
The root of the problem may in fact be in the kernel, and we can't very well ship the FC4 kernel in FC6.
It _is_ the kernel, we limited the commands we can send as users to disallow say a local user to flash the firmware and do damage. We are NOT asking you to ship an old kernel, that is an absurd suggestion which nobody proposed. There has to be an acceptable solution but despite asking for suggestions none has been proposed.
Can you state, without a doubt, what the exact problem is and an exact way to fix it?
I've been asking the same thing for ages mate, the lovely DaveJ hasn't been very responsive aside when he rejected the bug for FC5 and I'm just a mindless tester.
Nor have any of the suffering users been asked for additional information so I doubt any of us have a decent idea where to begin or we would probably have started poking around rather than doing those nasty suid hacks.
- David Nielsen
On Friday 28 July 2006 20:37, David Nielsen wrote:
I've been asking the same thing for ages mate, the lovely DaveJ hasn't been very responsive aside when he rejected the bug for FC5 and I'm just a mindless tester.
Nor have any of the suffering users been asked for additional information so I doubt any of us have a decent idea where to begin or we would probably have started poking around rather than doing those nasty suid hacks.
If it's a kernel thing, I highly doubt it's a Fedora patch that is doing this. This is really a case that should be taken upstream. Does this not effect other distributions that are using 2.6.16+ ?
fre, 28 07 2006 kl. 20:44 -0400, skrev Jesse Keating:
On Friday 28 July 2006 20:37, David Nielsen wrote:
I've been asking the same thing for ages mate, the lovely DaveJ hasn't been very responsive aside when he rejected the bug for FC5 and I'm just a mindless tester.
Nor have any of the suffering users been asked for additional information so I doubt any of us have a decent idea where to begin or we would probably have started poking around rather than doing those nasty suid hacks.
If it's a kernel thing, I highly doubt it's a Fedora patch that is doing this. This is really a case that should be taken upstream. Does this not effect other distributions that are using 2.6.16+ ?
It is an upstream change, that much is clear it is related to the SCSI command change from a while back, that does not mean we shouldn't at least propose a fix or ask the reporters for more information.. We know it's broken, we've known for months. This is probably the single most active bug I have ever had to deal with and all we've seen is users saying "me too".
I report bugs to Fedora, my life is to short to track down every single projects bugzilla, create accounts and repeat the information. I use Fedora, if the maintainer of the package feels the bug report needs to go upstream he can ask me to do so. The bug has not been closed as NOTOURBUG and it directly affects users of Fedora. It worked with FC4, we lived with the regression in FC5.. please don't make us suffer in FC6 as well.
- David
On Friday 28 July 2006 20:58, David Nielsen wrote:
It is an upstream change, that much is clear it is related to the SCSI command change from a while back, that does not mean we shouldn't at least propose a fix or ask the reporters for more information.. We know it's broken, we've known for months. This is probably the single most active bug I have ever had to deal with and all we've seen is users saying "me too".
I report bugs to Fedora, my life is to short to track down every single projects bugzilla, create accounts and repeat the information. I use Fedora, if the maintainer of the package feels the bug report needs to go upstream he can ask me to do so. The bug has not been closed as NOTOURBUG and it directly affects users of Fedora. It worked with FC4, we lived with the regression in FC5.. please don't make us suffer in FC6 as well.
DaveJ's comment still stands. We need a way in upstream kernel to have a list of safe commands per device. This infrastructure doesn't exist right now. The commands are sanitized at a different level. We could suid cdrecord, but that's a security flaw. We could just allow all commands, but what might be 'enable BURN-proof' on one drive may be 'flash firmware' on another. I seem to remember another distro had an issue that was perm damaging certain cdrom drives, I wonder if this is related. I'd much rather see a little necessary work around rather than blown up drives.
So we know what needs to be done, unfortunately our kernel team doesn't have the bandwidth to deal with this rightnow. Since this is in the kernel since around 2.6.8, I wonder what other distributions are doing to resolve this issue....
On Fri, 2006-07-28 at 21:13 -0400, Jesse Keating wrote:
On Friday 28 July 2006 20:58, David Nielsen wrote:
It is an upstream change, that much is clear it is related to the SCSI command change from a while back, that does not mean we shouldn't at least propose a fix or ask the reporters for more information.. We know it's broken, we've known for months. This is probably the single most active bug I have ever had to deal with and all we've seen is users saying "me too".
I report bugs to Fedora, my life is to short to track down every single projects bugzilla, create accounts and repeat the information. I use Fedora, if the maintainer of the package feels the bug report needs to go upstream he can ask me to do so. The bug has not been closed as NOTOURBUG and it directly affects users of Fedora. It worked with FC4, we lived with the regression in FC5.. please don't make us suffer in FC6 as well.
DaveJ's comment still stands. We need a way in upstream kernel to have a list of safe commands per device. This infrastructure doesn't exist right now. The commands are sanitized at a different level. We could suid cdrecord, but that's a security flaw. We could just allow all commands, but what might be 'enable BURN-proof' on one drive may be 'flash firmware' on another. I seem to remember another distro had an issue that was perm damaging certain cdrom drives, I wonder if this is related. I'd much rather see a little necessary work around rather than blown up drives.
So we know what needs to be done, unfortunately our kernel team doesn't have the bandwidth to deal with this rightnow. Since this is in the kernel since around 2.6.8, I wonder what other distributions are doing to resolve this issue....
You could also try asking Joerg nicely to make cdrecord's "generic MMC mode" actually limit itself to generic MMC commands, but I wouldn't hold my breath waiting for any help from him.
fre, 28 07 2006 kl. 18:27 -0700, skrev Nicholas Miell:
You could also try asking Joerg nicely to make cdrecord's "generic MMC mode" actually limit itself to generic MMC commands, but I wouldn't hold my breath waiting for any help from him.
I think there's a greater chance libburn will be useful before Joerg fixes cdrecord.. besides his attitude towards DVD support is rather special.
- David
On Fri, 2006-07-28 at 18:27 -0700, Nicholas Miell wrote:
You could also try asking Joerg nicely to make cdrecord's "generic MMC mode" actually limit itself to generic MMC commands, but I wouldn't hold my breath waiting for any help from him.
I suggest the asking will be done on another list since one flame war at the time is more than enough :-)
- Erwin
fre, 28 07 2006 kl. 21:13 -0400, skrev Jesse Keating:
On Friday 28 July 2006 20:58, David Nielsen wrote:
It is an upstream change, that much is clear it is related to the SCSI command change from a while back, that does not mean we shouldn't at least propose a fix or ask the reporters for more information.. We know it's broken, we've known for months. This is probably the single most active bug I have ever had to deal with and all we've seen is users saying "me too".
I report bugs to Fedora, my life is to short to track down every single projects bugzilla, create accounts and repeat the information. I use Fedora, if the maintainer of the package feels the bug report needs to go upstream he can ask me to do so. The bug has not been closed as NOTOURBUG and it directly affects users of Fedora. It worked with FC4, we lived with the regression in FC5.. please don't make us suffer in FC6 as well.
DaveJ's comment still stands. We need a way in upstream kernel to have a list of safe commands per device. This infrastructure doesn't exist right now. The commands are sanitized at a different level. We could suid cdrecord, but that's a security flaw. We could just allow all commands, but what might be 'enable BURN-proof' on one drive may be 'flash firmware' on another. I seem to remember another distro had an issue that was perm damaging certain cdrom drives, I wonder if this is related. I'd much rather see a little necessary work around rather than blown up drives.
So we know what needs to be done, unfortunately our kernel team doesn't have the bandwidth to deal with this rightnow. Since this is in the kernel since around 2.6.8, I wonder what other distributions are doing to resolve this issue....
My guess is that any distro that doesn't suffer from this (I'm a full on Fedora user so I haven't tested every single one out there) either revert the security patch or suid cdrecord.
The other distro you were thinking of was Mandrake 8 that killed lite-on drives, this was a hardware bug btw. I had one of those so I know that bug intimately. One of the reasons I went out and bought a Plextor drive was that for once I wanted a quality drive that didn't burn coasters and wouldn't suffer from this kind of bug. Imagine my horror when a drive that cost more than twice as much as a shoddy drive suddenly stopped working. Lesson learned, Linux works best on shitty hardware.
- David
It does not only affect Plextor users, I count TEAC as well and I have heard NEC also suffers. I also know of a number of users with unnamed hardware who has hit this problem.
This is a regression, it worked in FC4 and it was rejected for FC5 - I was under the impression that it would indeed be a target for fixing in FC6.
Ah, the bug report seemed filled w/ plextor users. I have a NEC at work and it works fine.
The root of the problem may in fact be in the kernel, and we can't very well ship the FC4 kernel in FC6.
Can you state, without a doubt, what the exact problem is and an exact way to fix it?
Pretty sure its not just plextos. My TSSTCorp drive in my Dell laptop can't burn cds from a non root user (but haven't tried it from root yet).
Peter
lør, 29 07 2006 kl. 13:59 +0100, skrev Peter Robinson:
It does not only affect Plextor users, I count TEAC as well and I have heard NEC also suffers. I also know of a number of users with unnamed hardware who has hit this problem.
This is a regression, it worked in FC4 and it was rejected for FC5 - I was under the impression that it would indeed be a target for fixing in FC6.
Ah, the bug report seemed filled w/ plextor users. I have a NEC at work and it works fine.
The root of the problem may in fact be in the kernel, and we can't very well ship the FC4 kernel in FC6.
Can you state, without a doubt, what the exact problem is and an exact way to fix it?
Pretty sure its not just plextos. My TSSTCorp drive in my Dell laptop can't burn cds from a non root user (but haven't tried it from root yet).
Broken drives according to the bug:
'PLEXTOR ' 'DVDR PX-716AL ' 'PLEXTOR ' 'DVDR PX-755A ' '1.02' 'PLEXTOR ' 'CD-R PX-W2410A' '1.04 NEC 3500A. PLEXTOR PX-W5224A SCSI PlexWriter CDRW Plextor 716A PlexWriter CD-R PX-W4012A plextor cd-r px-w4824a TEAC CD-R55S TSSTCorp
There's a clear pattern with regards to the Plextor drives, however we also see a number of other brands being knocked out by this. I would really love to know how widespread this bug is.
This also makes me wonder which drive I should buy to replace my lovely Plextor drive while I wait for this bug to go away - setting cdrecord suid does not seem to please nautilus-cd-burner in my case and I'd really love to burn DVDs in a non-ancient way.
- David
David Nielsen wrote:
lør, 29 07 2006 kl. 13:59 +0100, skrev Peter Robinson:
It does not only affect Plextor users, I count TEAC as well and I have heard NEC also suffers. I also know of a number of users with unnamed hardware who has hit this problem.
This is a regression, it worked in FC4 and it was rejected for FC5 - I was under the impression that it would indeed be a target for fixing in FC6.
Ah, the bug report seemed filled w/ plextor users. I have a NEC at work and it works fine.
The root of the problem may in fact be in the kernel, and we can't very well ship the FC4 kernel in FC6.
Can you state, without a doubt, what the exact problem is and an exact way to fix it?
Pretty sure its not just plextos. My TSSTCorp drive in my Dell laptop can't burn cds from a non root user (but haven't tried it from root yet).
Broken drives according to the bug:
'PLEXTOR ' 'DVDR PX-716AL ' 'PLEXTOR ' 'DVDR PX-755A ' '1.02'
PLEXTOR ' 'DVDR PX-755A ' '1.04' can be added to the list too :)
'PLEXTOR ' 'CD-R PX-W2410A' '1.04 NEC 3500A. PLEXTOR PX-W5224A SCSI PlexWriter CDRW Plextor 716A PlexWriter CD-R PX-W4012A plextor cd-r px-w4824a TEAC CD-R55S TSSTCorp
There's a clear pattern with regards to the Plextor drives, however we also see a number of other brands being knocked out by this. I would really love to know how widespread this bug is.
This also makes me wonder which drive I should buy to replace my lovely Plextor drive while I wait for this bug to go away
I have paid for a high quality burner and its useless because of a damn bug (regression!= that is known for mounths and no attepts to fix it have been made :(
- setting cdrecord suid does not seem to please
nautilus-cd-burner in my case and I'd really love to burn DVDs in a non-ancient way.
install the FC4 cdrecord, works fine here :(
- David
Le samedi 29 juillet 2006 à 18:31 +0200, David Nielsen a écrit :
Broken drives according to the bug:
'PLEXTOR ' 'DVDR PX-716AL ' 'PLEXTOR ' 'DVDR PX-755A ' '1.02' 'PLEXTOR ' 'CD-R PX-W2410A' '1.04 NEC 3500A. PLEXTOR PX-W5224A SCSI PlexWriter CDRW Plextor 716A PlexWriter CD-R PX-W4012A plextor cd-r px-w4824a TEAC CD-R55S TSSTCorp
You can add the Plextor 716SA to the list
This also makes me wonder which drive I should buy to replace my lovely Plextor drive while I wait for this bug to go away - setting cdrecord suid does not seem to please nautilus-cd-burner in my case and I'd really love to burn DVDs in a non-ancient way.
If you buy any semi-decent drive it'll have proprietary extensions and be blocked under Fedora
On Sat, Jul 29, 2006 at 06:41:41PM +0200, Nicolas Mailhot wrote:
If you buy any semi-decent drive it'll have proprietary extensions and be blocked under Fedora
The filter logic is from upstream. If the old cdrecord works and the new one doesn't then it sounds like the cdrecord package has changes to deliberately issue commands it doesn't need and then fail to fall back to mmc.
Strange, but then I find its maintainer a little odd in his choices
Le samedi 29 juillet 2006 à 19:14 -0400, Alan Cox a écrit :
On Sat, Jul 29, 2006 at 06:41:41PM +0200, Nicolas Mailhot wrote:
If you buy any semi-decent drive it'll have proprietary extensions and be blocked under Fedora
The filter logic is from upstream. If the old cdrecord works and the new one doesn't then it sounds like the cdrecord package has changes to deliberately issue commands it doesn't need and then fail to fall back to mmc.
Strange, but then I find its maintainer a little odd in his choices
I didn't think anyone would dare writing it, but this thought has occurred to me too
On Sat, Jul 29, 2006 at 06:31:40PM +0200, David Nielsen wrote:
There's a clear pattern with regards to the Plextor drives, however we also see a number of other brands being knocked out by this. I would really love to know how widespread this bug is.
This also makes me wonder which drive I should buy to replace my lovely Plextor drive while I wait for this bug to go away - setting cdrecord suid does not seem to please nautilus-cd-burner in my case and I'd really love to burn DVDs in a non-ancient way.
FWIW, I took this issue to the linux-scsi list last night, and awoke to find that the upstream maintainers of this code are now considering ripping out the command sanitising. Whether it'll be replaced something completely different or not remains to be seen.
Stay tuned..
Dave
Dave Jones wrote:
On Sat, Jul 29, 2006 at 06:31:40PM +0200, David Nielsen wrote:
There's a clear pattern with regards to the Plextor drives, however we also see a number of other brands being knocked out by this. I would really love to know how widespread this bug is.
This also makes me wonder which drive I should buy to replace my lovely Plextor drive while I wait for this bug to go away - setting cdrecord suid does not seem to please nautilus-cd-burner in my case and I'd really love to burn DVDs in a non-ancient way.
FWIW, I took this issue to the linux-scsi list last night, and awoke to find that the upstream maintainers of this code are now considering ripping out the command sanitising. Whether it'll be replaced something completely different or not remains to be seen.
Stay tuned..
Linus seems to dislike the idea and thinks that cdrecord is broken and not the kernel... the funny thing is I always used /dev/hdc or /dev/hdd with cdrecord and got affected by this bug.
Dave
On Sat, Jul 29, 2006 at 07:20:48PM +0200, dragoran wrote:
Linus seems to dislike the idea and thinks that cdrecord is broken and not the kernel...
Well, cdrecord should still be able to write a disc using generic commands so aborting when the vendor specific commands don't work is a bit extreme.
Dave
Dave Jones wrote:
On Sat, Jul 29, 2006 at 07:20:48PM +0200, dragoran wrote:
Linus seems to dislike the idea and thinks that cdrecord is broken and not the kernel...
Well, cdrecord should still be able to write a disc using generic commands so aborting when the vendor specific commands don't work is a bit extreme.
thats true , but even so this would be a bug, some plextor drivers have features to make sure the burned disk meets some kind of quality standard but this will require this commands to work. without them a 100$ plextor burner is allmost the same as a 25$ no name one :(
Dave
lør, 29 07 2006 kl. 13:23 -0400, skrev Dave Jones:
On Sat, Jul 29, 2006 at 07:20:48PM +0200, dragoran wrote:
Linus seems to dislike the idea and thinks that cdrecord is broken and not the kernel...
Well, cdrecord should still be able to write a disc using generic commands so aborting when the vendor specific commands don't work is a bit extreme.
Dave
This is Joerg we are talking about, he sometimes gets those ideas.
On Sat, Jul 29, 2006 at 12:53:02PM -0400, Dave Jones wrote:
that the upstream maintainers of this code are now considering ripping out the command sanitising. Whether it'll be replaced something completely different or not remains to be seen.
Well if they take it out they break the userspace API so it'll get vetoed, and it'll break all the gnome/kde userspace for good. If they take it out and let anything through then bugtraq will receive drive destroying tools the next day so that isn't viable.
The gentoo folks did a very nice fs interface for customising the sanitizer but for some reason it never got upstream.
Alan
Hi.
David Nielsen david@lovesunix.net wrote:
It does not only affect Plextor users, I count TEAC as well and I have heard NEC also suffers.
For what it's worth, I have a NEC drive (ATA via USB/Firewire, so SCSI applies, I think) and it works just fine.
On Sat, Jul 29, 2006 at 01:39:06PM +0200, Ralf Ertzinger wrote:
David Nielsen david@lovesunix.net wrote:
It does not only affect Plextor users, I count TEAC as well and I have heard NEC also suffers.
For what it's worth, I have a NEC drive (ATA via USB/Firewire, so SCSI applies, I think) and it works just fine.
Plextor drives have a whole mode of their own that isn't standard mmc. This includes various vendor commands we filter for safety.
Alan Cox wrote:
On Sat, Jul 29, 2006 at 01:39:06PM +0200, Ralf Ertzinger wrote:
David Nielsen david@lovesunix.net wrote:
It does not only affect Plextor users, I count TEAC as well and I have heard NEC also suffers.
For what it's worth, I have a NEC drive (ATA via USB/Firewire, so SCSI applies, I think) and it works just fine.
Plextor drives have a whole mode of their own that isn't standard mmc. This includes various vendor commands we filter for safety.
which is broken commands should only be filtered if they cause damage, but only because they may be able flash the firmware on a drive that may not even exists is IMHO not a fix but a bug.
dragoran dragoran@feuerpokemon.de writes:
which is broken commands should only be filtered if they cause damage, but only because they may be able flash the firmware on a drive that may not even exists is IMHO not a fix but a bug.
If you can issue such commands to the drive, you can easily: - become root - damage the drive
Should a chmod +w /dev/drive for a user give him root access to the system (which can't be stopped even with selinux)?
Krzysztof Halasa wrote:
dragoran dragoran@feuerpokemon.de writes:
which is broken commands should only be filtered if they cause damage, but only because they may be able flash the firmware on a drive that may not even exists is IMHO not a fix but a bug.
If you can issue such commands to the drive, you can easily:
- become root
- damage the drive
Should a chmod +w /dev/drive for a user give him root access to the system (which can't be stopped even with selinux)?
how could this lets a user become root? did one of this ever happend before 2.6.8.1 ? become root -> I am sure that this never happend (using a scsi command) 2 one possible but in that case we should block the commands that can damage the drive simply blocking almost all commands is no solution....
Dnia 29-07-2006, sob o godzinie 19:26 +0200, dragoran napisał(a):
If you can issue such commands to the drive, you can easily:
- become root
how could this lets a user become root?
Maybe he was thinking about sending commands to any drive? Speaking to hard disk drive one can edit /etc/passwd and so on. But we're talking about CD drives, how can a CD drive make me root? People have suid cdrecords on machines with shell accounts and to this point there was no exploit using SCSI commands to gain privileges (the only one I know of was using user-provided $RSH as root).
Lam
Leszek Matok Lam@Lam.pl writes:
People have suid cdrecords on machines with shell accounts and to this point there was no exploit using SCSI commands to gain privileges (the only one I know of was using user-provided $RSH as root).
Suid cdrecord with root-only drive access may be potentially safe, because users aren't allowed to issue arbitrary commands to the drive.
dragoran dragoran@feuerpokemon.de writes:
how could this lets a user become root?
Compromising firmware of one device on IDE bus = at least compromising both master and slave.
did one of this ever happend before 2.6.8.1 ? become root -> I am sure that this never happend (using a scsi command)
How about some proof? Security is not about "being sure".
2 one possible but in that case we should block the commands that can damage the drive simply blocking almost all commands is no solution....
How do you know which commands are dangerous? There is no standard for that. Chances are the standard commands are safe but nothing more.
On Sat, Jul 29, 2006 at 10:19:09PM +0200, Krzysztof Halasa wrote:
Compromising firmware of one device on IDE bus = at least compromising both master and slave.
You should assume host compromise because patched firmware can fiddle with things like setuid bits. Actually you should assume that you'll never use the device again and have to bin it. For most universities and many other environments thats probably worst case.
Alan Cox alan@redhat.com writes:
Compromising firmware of one device on IDE bus = at least compromising both master and slave.
You should assume host compromise because patched firmware can fiddle with things like setuid bits. Actually you should assume that you'll never use the device again and have to bin it. For most universities and many other environments thats probably worst case.
Precisely, though sometimes host compromise without actually destroying the writer may be a bigger problem than just a damaged drive (which, with a bit of luck, could be brought back to life).
Alan Cox wrote:
On Sat, Jul 29, 2006 at 01:39:06PM +0200, Ralf Ertzinger wrote:
David Nielsen david@lovesunix.net wrote:
It does not only affect Plextor users, I count TEAC as well and I have heard NEC also suffers.
For what it's worth, I have a NEC drive (ATA via USB/Firewire, so SCSI applies, I think) and it works just fine.
Plextor drives have a whole mode of their own that isn't standard mmc. This includes various vendor commands we filter for safety.
Couldn't we turn the command filter into a filter matrix based on the manufacturer ? this would solve the problem of A's harmless command is that same as B's firmware flash command. I would venture to say this matrix would be of manageable size if it only affected CD-ROM devices.
-denis cdrdao project
On Sunday 30 July 2006 10:27, Denis Leroy wrote:
Couldn't we turn the command filter into a filter matrix based on the manufacturer ? this would solve the problem of A's harmless command is that same as B's firmware flash command. I would venture to say this matrix would be of manageable size if it only affected CD-ROM devices.
That's whats been suggested to happen upstream in the kernel. However nobody has offered to do the work.
Jesse Keating wrote:
On Sunday 30 July 2006 10:27, Denis Leroy wrote:
Couldn't we turn the command filter into a filter matrix based on the manufacturer ? this would solve the problem of A's harmless command is that same as B's firmware flash command. I would venture to say this matrix would be of manageable size if it only affected CD-ROM devices.
That's whats been suggested to happen upstream in the kernel. However nobody has offered to do the work.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0409.1/2109.html the command for the drivers are in the cdrecord source...
Denis Leroy denis@poolshark.org writes:
Couldn't we turn the command filter into a filter matrix based on the manufacturer ?
It would have to involve model numbers as well.
On Sun, Jul 30, 2006 at 04:27:38PM +0200, Denis Leroy wrote:
manufacturer ? this would solve the problem of A's harmless command is that same as B's firmware flash command. I would venture to say this matrix would be of manageable size if it only affected CD-ROM devices.
Send patches
Jesse Keating wrote:
On Friday 28 July 2006 09:43, dragoran wrote:
We should fix this issue before realsing FC6 (or even test3) since this hits many users and cdburning is a task that every user will do from time to time (not like setting up a vm). So please do *not* release FC6 Test3 until this one is fixed!
Unfortunately because this seems to effect only plextor users, and there are some work arounds for it, I don't think this would classify as a blocker bug. But I'd sure like to see a PROPER fix for this (upsream), I just don't know if it can be done in time.
no ignoring this only because it only effetcs plextor users is _wrong_ if we can't fix it in time we should downgrade cd record to the fc4 version, but this can be fixed in the kernel; we only need to allow the commands that gets blocked by the kernel for all devices (not all commands but the commands that cdrecord uses)
On Saturday 29 July 2006 08:12, dragoran wrote:
no ignoring this only because it only effetcs plextor users is _wrong_ if we can't fix it in time we should downgrade cd record to the fc4 version, but this can be fixed in the kernel; we only need to allow the commands that gets blocked by the kernel for all devices (not all commands but the commands that cdrecord uses)
If I recall, there is significant reason why we updated cdrecord. I don't know those reasons off the top of my head.
The problem with allowing commands is that they are different per device. What might be BURNFREE for one device could very well be FLASH FIRMWARE on another device.
Hi.
Jesse Keating jkeating@redhat.com wrote:
The problem with allowing commands is that they are different per device. What might be BURNFREE for one device could very well be FLASH FIRMWARE on another device.
How, then, does cdrecord (or cdrdao) figure out which command to use for burnfree?
Hi.
Jesse Keating jkeating@redhat.com wrote:
I'm not entirely sure. Perhaps it gets this information from the device itself.
A quick look over the cdrdao sources suggests the following: in order to use burnfree your burner has to be compatible to the generic mmc standard (which virtually all non-ancient burners are, I think).
In that case, burnfree capability is announced at a standard place, and en-/disabled at a likewise standard place.
lør, 29 07 2006 kl. 15:18 +0200, skrev Ralf Ertzinger:
Hi.
Jesse Keating jkeating@redhat.com wrote:
The problem with allowing commands is that they are different per device. What might be BURNFREE for one device could very well be FLASH FIRMWARE on another device.
How, then, does cdrecord (or cdrdao) figure out which command to use for burnfree?
It asks the tiny Japanese people that live inside your computer..
Jesse Keating wrote:
On Saturday 29 July 2006 08:12, dragoran wrote:
no ignoring this only because it only effetcs plextor users is _wrong_ if we can't fix it in time we should downgrade cd record to the fc4 version, but this can be fixed in the kernel; we only need to allow the commands that gets blocked by the kernel for all devices (not all commands but the commands that cdrecord uses)
If I recall, there is significant reason why we updated cdrecord. I don't know those reasons off the top of my head.
breaking burning for many users isn't really a solution, we should try to fix the problem which should be solved by the update by backporting the fix or anything like this...
The problem with allowing commands is that they are different per device. What might be BURNFREE for one device could very well be FLASH FIRMWARE on another device.
where have you got this info from? sounds odd .. aren't such commands defined in some spec so that all devices uses them (correct me if I am wrong)
On Saturday 29 July 2006 09:36, dragoran wrote:
breaking burning for many users isn't really a solution, we should try to fix the problem which should be solved by the update by backporting the fix or anything like this...
Again, I'm pretty sure we can't roll back cdrecord for it breaks other things.
The problem with allowing commands is that they are different per device. What might be BURNFREE for one device could very well be FLASH FIRMWARE on another device.
where have you got this info from? sounds odd .. aren't such commands defined in some spec so that all devices uses them (correct me if I am wrong)
This was from Dave J. I REALLY doubt there is a singular spec that all burners use. Its different by manufacturer which is why we can't just say 'these commands are safe for all devices', it has to be on a per-device level and the kernel currently can't handle that. Needs to be fixed in the upstream kernel.
Dnia 29-07-2006, sob o godzinie 09:40 -0400, Jesse Keating napisał(a):
Its different by manufacturer which is why we can't just say 'these commands are safe for all devices', it has to be on a per-device level and the kernel currently can't handle that. Needs to be fixed in the upstream kernel.
This way the kernel has to be taught which device is a burner, have an API to switch modes (or transparently sniff SCSI commands to know which mode the burner is in) and for every burner model has big lists of commands allowed in each of its modes of operation.
We all know cdrecord already knows or pretends to know what to say to which device. Did it EVER make a burner explode or something? (The Mandrake thing with LG/Lite-On was about CD-ROM-s and kernel, not cdrecord)
I have ATA DVD-ROM and SCSI CD-R in this FC5 machine. The kernel doesn't say anything in dmesg about my burner being a burner, but hal knows that (lshal says storage.cdrom.cdr = true).
It's possible to give cdrecord some specific selinux attributes (type?). Maybe it would be possible to give this process full access to devices with some other specific attribute. The script which takes lshal's output and does some chcon on every burner device is trivial, probably a patch to udev would be better (I'm not into its workings) and can be done.
This way we can be sure cdrecord is not allowed to send any commands to devices not being CD burners, but is allowed to do anything it wants with the burners. What can happen? FLASH FIRMWARE? Come on, we're talking about cdrecord and its privileges, not any other process in the system. I trust cdrecord to the point of making it suid root (thanks for making it work in updates-testing for FC5, BTW), I'd trust it even more when it runs with user right + the right to send whatever it wants to the only burner in my computer.
So the question is: can it be done with SELinux?
Lam