Hide Forgot
Description of problem: When running cdrecord without setuid (as it comes as default), cdrecord reports: cdrecord: Cannot allocate memory. WARNING: Cannot do mlockall(2). cdrecord: WARNING: This causes a high risk for buffer underruns. cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler cdrecord: Permission denied. WARNING: Cannot set priority using setpriority(). cdrecord: WARNING: This causes a high risk for buffer underruns. And it is pretty true. It is very likely that I will run into buffer underruns if I try to use my computer for any other thing (even the screensaver entering destroys the burning process). Setting setuid on cdrecord executable fixed the problem, I could even start heavy applications like OpenOffice.org without having problems with burning DVDs. But now, with the release of kernel 2.6.18-1.2200, cdrecord stopped working as setuid, giving the message: cdrecord: Resource temporarily unavailable. Cannot get mmap for 4198400 Bytes on /dev/zero. I haven't looked into cdrecord source code, but the fix seems to be trivial: drop root privileges before trying to do the offending mmap. Running cdrecord as root (via login or sudo, not setuid) works as expected, but this implies either breaking system security and/or having to manage wrapper scripts. Version-Release number of selected component (if applicable): Cdrecord-Clone 2.01.01a03-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2005 Jörg Schilling How reproducible: always Steps to Reproduce: 1. (as root) chmod +s /usr/bin/cdrecord 2. (as user) cdrecord blank=disc Actual results: cdrecord: Resource temporarily unavailable. Cannot get mmap for 4198400 Bytes on /dev/zero. Expected results: Burn the disk (as it was in 2.6.17).
cdrecord should not need the "s"-bit ... $ ulimit -l unlimited is the key
Like I said, without the "s" bit, cdrecord have problems with buffer underruns if I do anything else while burning. You are right that ulimit is limiting the site of locked memory, but it is a hard limit, I don't seem to get it past 32k as normal user. And for some reason, without the "s" bit this problem is not triggered.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
The replacement of cdrecord, wodim, fixed this bug. It does memory allocation, page locking and privilege dropping in the right order, and the executable can be set as setuid root.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
closing as requested in comment #4
There is a workaround for this idiosyncratic behavior of the Linux Kernel. This workaround is available since January 2006 in the original software. Please note that you _definitely_ need root privileges in order to be able to correctly send all needed SCSI commands through Linux anyway. For a fiy, just uograde to recent original software from: ftp:/ftp.berlios.de/pub/cdrecord/alpha/