Barry Brimer wrote:

Quoting Alex White ethericalzen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org:

...

When running k3b I get an error stating that cdrecord did not exit properly. And k3b will not burn a cd.

Running cdrecord from the command line as such:

/usr/bin/cdrecord -v gracetime=2 dev=/dev/hdd speed=40 -dao driveropts=burnfree -eject -data /home/fakeuser/cdimage.iso

I am met with a Segmentation fault. There is no other error obviously.

Any ideas? I'm running this as a regular user. Root does not encounter this problem. So the iso is perfectly fine.

What permissions does cdrecord need to be run as a regular user or should I be using sudo to burn a cd using cdrecord anyhow? Should cdrecord be suid?

There is a statement about burning CDs as a non-root user under 2.6.8+ kernels at the main page for cdrecord http://cdrecord.berlios.de/old/private/cdrecord.html

The summary version is: Burn CDs as root.

Barry Brimer

Thanks. However, running k3b as a regular user did at one time work, but that's really not much of an issue to me. I suppose then I should change cdrecord to run suid and that will solve my problem. Thanks for the linkage as well I'll read up on it.

Alex White

On Mon, 2005-11-28 at 17:15 +0100, Ralph Angenendt wrote:

That has been fixed in later versions of the kernel

There's no "fix." The kernel now differentiates between suid root and actually running as root, removing a lot of crucial access for the former. It was a very, very good security move IMHO.

Jorg's cdrecord just dies if it isn't granted certain priority, which it assume it has if its running suid root as well as actually as root. He either needs to not crap out if the kernel denies him priority, or test if the program is running suid and act accordingly.

(no, it's not 2.6.8+, it's only 2.6.8 AFAIR) - and surely has been fixed on CentOS, as I do not have any problems burning CDs as a non- root user.

As I mentioned before, in the few extra months of the Red Hat Linux 9 to Fedora Core 1 switchover, there were a lot of "sanity checks" done on the packages. From trying to map dependencies and reduce inter-RPM dependency hell on the base packages to getting rid of a lot of back security defaults -- the latter attitude removed suid on cdrecord.

As such, when Fedora Core 2 was updated to kernel 2.6.8.x+ with this "kernel security change," it works flawlessly, without issue. The issue _only_ occurs if suid root is set on cdrecord. RHEL 4 (and CentOS 4) inherit these defaults.

| [angenenr@shutdown ~]$ls -l /dev/hdc | brw------- 1 angenenr disk 22, 0 Nov 9 14:34 /dev/hdc I would think that udev does that for me.

The problem isn't with permissions, although Red Hat's console.perms and, in FC3+/RHEL4+, udev handles setting up device access for the console user proper. Too many other distros just suid too many binaries to bypass proper permissions on devices.

The problem is distros with ... $ ls -la `which cdrecord` -rwsr-xr-x 1 root root 366944 Oct 18 2004 /usr/bin/cdrecord ^ suid root ^

On FC1+, you'll see: $ ls -la `which cdrecord` -rwxr-xr-x 1 root root 366944 Oct 18 2004 /usr/bin/cdrecord

So when FC2+ came around (RHEL4 being based on FC3), and the 2.6.8.x+ update came out, *0* issues resulted. Unless someone manually set suid root on cdrecord.

The problem isn't device permissions. It's the elevated priority that Jorg's cdrecord tries to gain because it thinks its running as root. It craps out if they aren't granted. Again, he either needs to A) not crap out if they are not granted, or B) test for suid root on the cdrecord binary and not request the additional kernel priority on kernel 2.6.8.x +.

There is "no fix" for a "good security default."

[ Now I'm waiting for the countless people to compare this change to SELinux and other things that "break past behavior." ;-]

On Mon, 2005-11-28 at 10:56 -0600, Les Mikesell wrote:

What's a 'console user' in the context of unix-like systems?

Whomever logs in locally to X display :0.0, if X is used, or one of the physical ttys if not -- which may include the COM port (if /dev/console is so redirected).

Red Hat assigns permissions to devices based on who logs in. Those are configured in /etc/security/console.perms. Newer udev requires additional considerations.

On Mon, 2005-11-28 at 10:57 -0600, Alex White wrote:

Thanks Bryan and Ralph. Suid was set on cdrecord, I believe I did this on accident while testing something out with cdrecord and basically shot myself in the foot. Thats what happens when you follow a guide without question.

The kernel 2.6.8.x suid root security change is one of the most widely mis-understood changes. It doesn't help that Jorg (who I normally respect) says the kernel is broken, when it is is anything but broken.

I discovered that suid wasn't set on cdrecord in Fedora Core 1 when I was trying to record something remotely -- so the user didn't have device access, like in the past on RHL8/9. So I then did a comparison of suid between RHL8/9 and FC1 and saw all the things suid root had been removed from.

One of the two largest complaints about RHL prior to FC was the number of binaries suid root (the other being stupid inter-dependencies in the base packages). So I was surprised to see that cleaned up in FC1, and did some research confirming the "new attitude."

Appreciate the information and help. That was very informative Bryan, much obliged.

I was traveling and local to a LUG that was very anti-Red Hat, heavy Fedora bashers (this was when Fedora Core 2 had been released -- with all the heavy GCC, GLibC and kernel changes). It was a real vindication to say, "hey, Red Hat got it right with Fedora, they're listening!"

BTW, the simple "fix" is always (on any other distro): # chmod u-s `which cdrecord`