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