Bug 212281

Summary:	kernel 2.6.18 breaks setuid cdrecord
Product:	[Fedora] Fedora	Reporter:	Juliano F. Ravasi <bugs+fedora>
Component:	cdrkit	Assignee:	Harald Hoyer <harald>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9	CC:	petrosyan, schily, triage
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:	bzcl34nup
Fixed In Version:	wodim	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-07-09 04:53:14 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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

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

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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

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

ftp:/ftp.berlios.de/pub/cdrecord/alpha/