User-Agent: Build Identifier: K3B setups up a default group of 'cdrecording' it will make the changes to /etc/group and chgrp to /usr/bin/cdrdao and /usr/bin/cdrecord to 'cdrecording' group. It will also add any User you pick to the 'cdrecording' group.It will then copy the /etc/group file to /etc/group.k3bsetup. It will not work though. You can make it work various ways: 1) Chown to The User on cdrdao and cdrecording. Not good only lets one user in then. 2) Chgrp to 'users' group. Will work. What don't work: 1) Group 'cdrecording', even though User is in the 'cdrecording' group. 2) Chgrp to 'cdrw'. 3) Adding (have to do manually, KUser won't do it) 'cdrecording' group to 'users' group. Even though it shows up in /etc/group.k3bsetup when rerun kd3bsetup. Not sure exactly what to do. 1) Either make a ebuild note to not use the default group of 'cdrecording' but The Users primary default group of 'users' or whatever their default group is. 2) Change K3B to use the Primary Group as default. 3) Fix what is causing 'cdrecording' group to not work. Forum thread at: http://forums.gentoo.org/viewtopic.php?t=32494 Reproducible: Always Steps to Reproduce: 1.Install K3B 2.Run k3bsetup, leave the default 'cdrecording' group in place. 3.Let k3b make the changes to groups and fstab (it won't use the same device as other CD Burner programs and it won't let you add one. Maybe another bug? I use /dev/sr0 with all my other Burners and works. K3B won't let you add it like that.) 4. Try to use the Burner as USER. Click on the Settings/Configure K3b/Programs. Cdrdao and cdrecording will not be found and using the search button doesn't fix it. 5. Run through k3bsetup again. Change the default group to 'users' and it will work. Actual Results: Except for doing #5 the user cannot use the program unless running as root. Expected Results: The Setup was suppose to take care of making all the necessary changes so system Users added to it can use the program. It doesn't.
spider: another cd burner w/permission issues
Ya, Gcombust usually complains that you aren't root or don't have the permissions set when you do. But K3b states that it is Setup and going to setup the permissions specifically so that users can use the burner.
k3b 0.7.5 works for me, without needing to allow k3bsetup to make any changes to permissions/owners/groups. Gentoo's default pam_console setup means that the locally logged on user is automatically made the owner of the scsi generic devices. It all 'just works'. A possible answer for the original reporter: are you aware that after adding yourself to a new group you need to log out, then log back in for the new group to take effect? Your problems are consistent with not doing this.
Well... here cdrdao, cdrecord are installed (by their ebuilds) as world-excutable. Any permission issue is I think handled on getting write access to the cdrw devicefile. Is this wrong?
> Is this wrong? The ebuild isnt wrong, but it doesnt follow the permissions recommendations made by the cdrecord man page: 1. make cdrecord (and cdrdao) setuid root, to improve its reliability 2. create a seperate 'cdburners' group, to avoid yet another word-executable setuid root program Im not sure whether this is worth improving in the cdrecord ebuild. As a completely seperate question, k3b has a GUI setup process that offers to make these changes. It also wants to include some other changes that are not so sensible - such as changing permissions on some device nodes which pam_console will immediately overwrite. I understand the redhat distribution of k3b has this page removed from k3bsetup. It may be worth adding a note to the k3b ebuild saying something like: """ The K3b Setup program will offer to change some permissions and create a user group. These changes are not necessary. We recommend that you clear the two check boxes 'let k3b make changes for cdrecord and cdrdao' and 'let k3b make changes for the devices' when running K3b Setup. """
Does this issue still persist? k3b 0.8.1 is now available (as well as 0.9_pre1).
nothing has changed in k3b 0.8.1, and there is no sign of any difference in the 0.9.x changelog. I have had one colleague who was confused by this same issue. I think adding the warning I wrote at the end of #5 to the k3b ebuild would avoid this confusion.
Warning has been added to 0.9 ebuild.
