K3B Growisofs Problem on --Ccurrent Fixed

I have had a problem burning optical disks with K3B on --Current as user. When I started the application as user, I got an error message saying that K3B cannot find growisofs.

I could burn disks as root.

Tonight, I finally got annoyed enough to look into it, in an effort to answer a Linux Question. I fixed it by changing the permissions of /usr/bin/growisofs.

Here's what I did, in case it might help someone else.

bash-4.4$ locate growisofs
/usr/bin/growisofs
/usr/include/k3bgrowisofswriter.h
/usr/man/man1/growisofs.1.gz
/usr/share/zsh/5.3.1/functions/_growisofs
bash-4.4$ cd /usr/bin
bash-4.4$ ls -l growisofs
-rwxr-x--- 1 root burning 105808 Apr 14  2011 growisofs
bash-4.4$ su
Password: 
bash-4.4# chmod 774 growisofs
bash-4.4# ls -l growisofs
-rwxrwxr-- 1 root burning 105808 Apr 14  2011 growisofs

Once I made that change, I could start K3B as user without errors.

(Aside: Eleven years ago, I would not have understood a word of that.)

I encountered the same issue awhile ago. Nice solution! I fixed the issue in XFCE by first clicking on Applications----->Multimedia---->K3b----->Settings----->Setup System Permissions. Within the Setup System Permissions window I checked the box beside growisofs. After clicking apply and OK I was prompted to authenticate as root. I can now burn media as a regular user.

Would adding oneself to the 'burning' group accomplish the same thing?
Seems the group is there for a reason?
Just wondering
John

I'm wondering myself why the burning group is there. My machine doesn't have it, and Slackware doesn't ship with it. And furthermore, the default permissions on /usr/bin/growisofs are rwxr-xr-x, owned by root:root.

That said, the issue I see trying to use k3b as a normal user is that it will tell me that cdrecord doesn't have permission to open the device. My user is part of the cdrom group, and that group has write permission for /dev/sr0 which is the DVD-RW drive.

The usual solution for this is to make /usr/bin/cdrecord setuid root (chmod 4711). I don't do this by default because it is a large binary and I don't trust that doing this wouldn't expose a possible local root hole. But on your own non-server machine it's probably safe enough to consider.

Thanks for the explanation, I have been wondering why cdrecord was that way as I have this silly script to wrap around it.

https://notabug.org/orbea/burncd/src/master/burncd