Description of problem:
k3b can't be used anymore in FC28 to burn CDs without tweaking wodim's binary permission to u+s
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. upgrade to FC28
2. start k3b
Settings -> Configure -> Devices
In order to give K3b full access to the writer device the current user needs be added to a group cdrom.
The Permission helper that could do this for you was not enabled during build.
Please rebuild the package with the Permission helper enabled or contact your distribution.
3. add user to group cdrom
4. restart k3b -> message disappears
5. try to burn a CD
cdrecord permission problem CD can't be burned
/usr/bin/wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.
scsibus: -2 target: -2 lun: -2
/usr/bin/wodim: Cannot allocate memory.
Cannot open SCSI driver!
For possible targets try 'wodim --devices' or 'wodim -scanbus'.
For possible transport specifiers try 'wodim dev=help'.
For IDE/ATAPI devices configuration, see the file README.ATAPI.setup from
the wodim documentation.
TOC Type: 1 = CD-ROM
chmod u+s /usr/bin/wodim
it is working again (but this is somehow dangerous)
Strangewise, reduction to
chmod o-rwx /usr/bin/wodim
chgrp cdrom /usr/bin/wodim
is also not working, looks like the group membership "cdrom" isn't really used.
Reproduced on 2 systems
I can confirm the issue, and the workaround is working fine. Thanks!
I can confirm this issue as well. Additionally I had to add my user to the cdrom group (where it should have been by default I think?).
Please see my comment #5 to Bug 1583845 for an analysis of the problem.
wodim only exists because a hostile and uninformed Debian packetizer believed that writing optical media does not need special privilleges while starting personal attacks against me in May 2004.
His claim never has been true for any platform and this never has been true for Linux.
Since the main method used to "make the claim to apparently work" was to remove security checking code, I cannot tell whether wodim is a security risk when installed sid root.
The original software always was and is autited for security in this mode and not a risk.
In addition, cdrecord supports to work with fine grained privielleges on Solaris since January 2006 and after Linux added similar support in 2013, the fine grained privilege support was enhanced to Linux.
I recommend to use recent original software instead of the long dead code that was only seen as a hostile social attack froM Debian.
Check the most recent orignal code as part of the schilytools at:
For what ever it tells:
In F29 k3b works as expected just out of the box
Adding on to this, on F29 Brasero and K3B are bugging out unless I chmod that file as above, even if I am part of the cdrom group.
I'm attaching the relevant parts of my before log from Brasero, I don't have one handy for K3B.
BraseroWodim called brasero_job_set_current_action
BraseroWodim got varg:
BraseroWodim Launching command
BraseroWodim called brasero_job_get_fd_out
BraseroWodim called brasero_job_get_fd_in
BraseroWodim called brasero_job_get_fd_out
BraseroWodim stderr: wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.
BraseroWodim called brasero_job_get_flags
BraseroWodim stdout: TOC Type: 0 = CD-DA
BraseroWodim stderr: wodim: Resource temporarily unavailable. Cannot get mmap for 16781312 Bytes on /dev/zero.
BraseroWodim called brasero_job_get_flags
BraseroWodim stdout: HUP
BraseroWodim stderr: HUP
BraseroWodim process finished with status 11
BraseroWodim called brasero_job_error
BraseroWodim finished with an error
BraseroWodim asked to stop because of an error
error = 0
message = "no message"
Session error : unknown (brasero_burn_record brasero-burn.c:2859)
My comment #3, analysis and workaround without setuid bits still hold. Please see https://bugzilla.redhat.com/show_bug.cgi?id=1583845#c5
The background is that wodim has been created in order to harm the original cdrtools.
The people from Debian removed all consistency checks that exist in the original software. This is why you see the behavior from above.
before May 2004, Linux required root privileges to be able to open /dev/sg* with write permissions which was required to send any SCSI command.
Then a novice programmer (Douglas Gilbert) added ioctls without checking for permissions and introduced a big security problem.
Linus Torvalds in May 2004 did not fix that security problem but rather made an incompatible change to the /dev/sg interface.
This modification allows to send *some* SCSI commands without being root but fails to allow all needed SCSI commands for CD/DVD writing.
The Debian people behind the campaign against cdrtools miss the skills to understand this problem and created
a fork from cdrtools in May 2004, This fork is full of Debian specific bugs and never has been fixed since then.
The original cdrtools introduced a root-less method since Linux added support for fine grained privileges in 2013.
Note that the original code has been audited for safe suid root installation and for fine grained privs but
"wodim" only allows unverified suid root installation.
It is recommended to use the actively maintained original software instead of the Debian fake.
(In reply to Albert Flügel from comment #7)
> My comment #3, analysis and workaround without setuid bits still hold.
> Please see https://bugzilla.redhat.com/show_bug.cgi?id=1583845#c5
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 28 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
it looks like after upgrade to F30 no changes are required
Even if the newer version did install this fake program with the needed permissions, this is not
the solution for the general problem that is caused by the fact that "cdrkit" is full of other
bugs and completely unmaintained.
k3b was written for the original cdrtools software and not for the buggy "cdrkit" and
"cdrkit" was not created in order to solve a OSS problem but rather in order to attack the OSS
system, read the background:
In May 2004 - 15 years ago, some hostile people from Debian started with the original cdrtools source from that
time and created a fishy variant by adding approx. 100 bugs in total to all relevant programs (cdrecord, cdda2wav,
readcd, mkisofs, ... see the Debian bug data base from that time that documents the bugs and the fact that they
never have been fixed.
Since these people from Debian also removed Copyright notices, the modified source from Debian is not legal
for various reasons. In 2005, Debian started with a defamation campaign against cdrtools based on nothing but
libel and slander. This is of course illegal as well.
BTW: because of these bugs, the permission to use the original names for the programs in the Debian variant
has been withdrawn in August 2006 and this resulted in the rename of the programs in September 2006. An act
that later has been incorrectly called the "Creation of a fork" by Debian even though that beast exists since
May 2004 already (see the identical list of Debian specific bugs).
Since the end of 2004, no relevant modifications have been applied to that modified Debian source and in
May 2007 all activities (except some typo fixes) finally stopped. There are rumors that the the main actor
did this all just in order to get visibility for better chances to get a job at "Nero" and has been forbidden
to continue with his attacks by his new boss after he got that job.
As a result, nearly all of the bugs that have been introduced in 2004 are still present and no will at Redhaẗ́s
side to fix that situation is visible. In special, given that 15 years passed meanwhile, there does not seem to
be any hope that this buggy cdrkit will ever be fixed - regardless of what Fedora version you are using.
At the same time, major development activities have been applied to the original source. Dozens of important
bugs (that affect the integrity of the created filesystems) have been fixed in mkisofs and all programs from
the suite more than doubled their features.
It may be important to know that all major sites that asked their legal department for help (e.g. Suse, Sun,
Oracle) ship the original cdrtools suite and that Redhat did never asked a lawyer for help. So the fact that
Redhat still does not ship the original software seems to be some sort of own defamation campaign. It would
be interesting to see whether IBM is willing to support that lawless state of Redhat in the future.
There is a simple way to get rid of many bugs: toss cdrkit to where it belongs, into the junk yard and start
shipping the legal and much better original software that still gets frequent updates (see the schilytools
tarballs for verification that are published in an average bi-weekly frequency).
Note that there never has been any legal problem in the original sources. All programs (except mkisofs) are
100% CDDL - a fully accepted OSS license. Mkisofs is a GPLd program that uses some CDDLd libraries. This is
a method that has been approved by Eben Moglen, since he fully accepted the use of GNU tar (a GPLd program)
legally on OpenSolaris, where it uses CDDLd libraries.
So we need to check whether Redat will continue to ignore their users or whether Redhat will come back to the
"bright side of the Source". I have few hope but I am open for a change.
*** This bug has been marked as a duplicate of bug 1583845 ***