Bug 212281 - kernel 2.6.18 breaks setuid cdrecord
Summary: kernel 2.6.18 breaks setuid cdrecord
Alias: None
Product: Fedora
Classification: Fedora
Component: cdrkit
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2006-10-26 01:16 UTC by Juliano F. Ravasi
Modified: 2009-01-24 22:43 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2008-07-09 04:53:14 UTC

Attachments (Terms of Use)

Description Juliano F. Ravasi 2006-10-26 01:16:24 UTC
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

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

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

Expected results:
Burn the disk (as it was in 2.6.17).

Comment 1 Harald Hoyer 2006-10-26 08:36:40 UTC
cdrecord should not need the "s"-bit ...
$ ulimit -l unlimited 
is the key

Comment 2 Juliano F. Ravasi 2006-10-26 21:42:05 UTC
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.

Comment 3 Bug Zapper 2008-04-04 04:07:04 UTC
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.

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:

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

Comment 4 Juliano F. Ravasi 2008-05-02 19:04:43 UTC
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.

Comment 5 Bug Zapper 2008-05-14 02:26:08 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 6 petrosyan 2008-07-09 04:53:14 UTC
closing as requested in comment #4

Comment 7 Jörg Schilling 2009-01-24 22:43:43 UTC
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

For a fiy, just uograde to recent original software from:


Note You need to log in before you can comment on or make changes to this bug.