Grafpup-2.xx fourth (and final) alpha

[Nathan F]

Sounds good. Could you possibly make your binaries available? That way all I have to do is change the burner wizard (and possibly Grafburn) to do the chmod, and the problem should then be resolved for anything using cdrecord.

Nathan

[plinej]

sure, I'll make up a .pet package and post it here. It will include cdrskin, libburn and cdrecord as a symlink that will overwrite the original.

[plinej]

Okay, here it is. I'll burn an audio disk tomorrow and see if it works out okay but I would imagine it should after reading thru this web page:

http://scdbackup.sourceforge.net/cdrskin_eng.html

[SimonW]

I checked my kernel config and found a couple errors relating to sata, so I'm going to be recompiling the kernel again. I'll of course be needing testers with sata hardware.

That'll be me then...!

I'll keep a close eye out here and on grafpup.org, and when I see a testing or other iso, I'll get straight on it.

[Nathan F]

After reading over the docs everything looks kosher, and actually quite good. I'll be working on incorporating this and the required changes to the burner wizard in a couple hours.

Nathan

[plinej]

Sounds good. I just burned an audio disc with grafburn as grafpup and it seemed to burn fine. I went to rip a track with pbcdripper and noticed that the resulting track was owned by root. I didn't encode but just ripped to wav. I would think if I tried to encode to something I wouldn't be able to since root owns the file. Therefore there's still an issue with root owning the device.

[plinej]

nevermind, I seemed to have been running PBcdripper as root even though I'm logged in as grafpup and I selected it from the menu. When I run PBcdripper from the cli the resulting files are owned by grafpup:users.

[plinej]

I'm not sure why this would make a difference but I seem to run PBcdripper as root when selecting from the menu unless I change the exec function in the .desktop file from "/usr/local/bin/PBcdripper" to just "PBcdripper". Should that make a difference?

[Nathan F]

Well no, it shouldn't. Actually, I never did anything to PBcdripper that should have any effect on what user it runs as. Maybe the panel ran as root? I don't know.

Nathan

[Nathan F]

Ooh, big problem now. Cdrskin doesn't support the blank option yet, so that breaks any frontend that uses it. I'll need to rethink a bit.

Nathan

[plinej]

Yep, you're right. I didn't notice that. Hopefully that will be resolved soon. I can package up wodim for you if you'd like to try that.

[plinej]

If you want to try wodim instead it is set up the same way with cdrecord as a symlink to wodim. It depends on libcap which I'll also post. I forgot to strip that library initially but have done so now and it is only 9.969 kilobytes.

wodim is part of cdrkit which is debian's fork of cdrtools.

[plinej]

We could also use cdrdao to blank cdrw's instead. Just have cdrecord as a wrapper script that starts cdrdao if blank is found in the command and if not pass it on to cdrskin.

[Nathan F]

That sound promising. What I'm trying to do is avoid setting the cdrecord executable suid root. It works, but it's also been proven to be a security risk.

Any such wrapper would also have to know how to translate any arguments ino commands that cdrdao understands.

Nathan

[plinej]

Yep, I can work on it if you don't want to and then post a script here.

[plinej]

The only thing is cdrecord/wodim can blank specified tracks & sessions as well as the entire disk whereas cdrdao can only blank the full disc (minimal or full).

[plinej]

It might be best to keep cdrecord and rename it to something else or use wodim for the blanking of discs and everything else can be passed to cdrskin. Something like this:

Code: Select all

#!/bin/bash
#save as /usr/bin/cdrecord

if [ "`echo "$@" | grep blank`" != "" ]; then
wodim "$@"
else
cdrskin "$@"
fi

exit 0

[plinej]

Well this may all be avoided. Did you read the page at:

http://scdbackup.sourceforge.net/cdrskin_eng.html

They have examples of blanking posted using cdrskin. Did you try it or just notice it wasn't in the help display? I'm going to give it a try soon.

[plinej]

Forget about the wrapper scripts, cdrskin blanks just fine. They need to add that to the help screen but otherwise the program still works.

[Nathan F]

Well, when I tried with the binary you posted it shot back that the blank option was not supported. I could try again I suppose, but I'm away from that computer now.

We could also retain cdrecord (or wodim) under a different prefix, say put it in /opt/cdrkit/bin. I'd rather get down to just one "cdrecord" executable, though.

Yet another option would be to do this the Ubuntu way, and allow all users to run cdrecord via sudo. I'd almost rather just install the binary suid root, though. And from my poking around it would seem that the latest versions of cdrecord have been fixed up to make this less of a security issue than before.

There was an incident a while back, in which Jörg Schilling said that the Linux kernel probably had more vulnerabilities than cdrecord installed suid root. He may have been right, but it set off a volly of criticism, and also prompted a few hackers to check out his claim. They found a pretty major vulnerability, where cdrecord did not give up root priveledges and could be exploited to escape to a shell. This is kind of the heart of the controversy right now, but from what I have read he promptly closed that exploit.

So basically, I could probably end all this by compiling the latest cdrtools source and installing it suid root. But I've been a little hesitant to do so, because of all the conflicting information on the net. I'm not one to get all worked up about other hacker's paranoia, really, but the problem is I can't find any definative answer to the question of whether that exploit is really closed.

I'm really going to have to save some of this for later anyway though, as we're getting ready for a trip to see my wife's family over the weekend.

Nathan