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." ;-]