Bryan J. Smith wrote:
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.
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." ;-]
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.
Appreciate the information and help. That was very informative Bryan, much obliged.
Thanks!
Alex White