[diehl]

I just upgraded from 2007.0 to 2007.1 and now k3b says it should be run with "root privileges". I do not know what k3b wants me to do. I tried activating the suid bit on k3b (chmod +s /usr/bin/k3b) but then k3b will not run at all (as an ordinary user). I suppose I could run k3b from root, but this is not convenient and generates many warnings. Just what "root' privileges does k3b want?

[ffi]

did you try running the set up wizard? When you run the wizard it asks for your root password and sets everything up automatically, you also might have to have sudo installed but i am not sure about that for that to work...

[diehl]

Thanks for info. Next dumb question - how do I get k3b to run the setup wizard? I do not see any menu options for it in the k3b program, nor any setup programs packages in the k3b rpm, nor any packages called k3b-setup or similar. I looked for a ~/.k3b* folder to delete (and perhaps induce the setup program), but found none.

[neddie]

Try running the command

k3bsetup

from a console.

[Greg2]

diehl, on May 5 2007, 08:40 AM, said:

I just upgraded from 2007.0 to 2007.1 and now k3b says it should be run with "root privileges".

I've found that on my system it works fine being run as user, I have had no problems burning CDs or DVDs.

[neddie]

Oops sorry, I was basing my answer on 2007. I've just noticed that when running a live version of 2007.1 (I've not installed it yet) running k3b brings up the following popup:

Quote

cdrecord will be run without root privileges
It is highly recommended to configure cdrecord to run with root privileges. Only then cdrecord runs with high priority which increases the overall stability of the burning process. Apart from that it allows changing the size of the used burning buffer. A lot of user problems could be solved this way. This is also true when using SuSE's resmgr.

And for some strange reason there's no /usr/bin/k3bsetup. Weird.

[diehl]

Well quite probably I could run k3b without root privileges, but since k3b advises you to do this, I would prefer to do it, to minimize producing toasters.

Somebody who has k3bsetup on there system could do this:
$ which k3bsetup # will output something like:
/usr/bin/k3bsetup
$ rpm -qf /usr/bin/k3bsetup #will tell you which rpm has k3bsetup

All I can say is that k3b-1.0-3mdv2007.1 which is Mandriva 2007.1 installs does not have this program.

[AussieJohn]

I think you will find it is not there because it is no longer needed. It doesn't show up in my 2007.1 Spring either and I have had zero problems burning CDs or DVDs. Frankly I think you are worrying about nothing.

If I remember correctly, the message you get gives you a choice to have the message to appear each time K3B is opened or not. The sensible thing is to remove the tick and it will no longer reappear. The earlier Configure K3B only really required you to put a tick in a box and click apply. I believe it now does that by default i.e. automatically.
Cheers. John.

[scarecrow]

I do *not* think K3B asks you to run it with root priviledges- rather the opposite!
I guess it tells you that cdrecord, cdrdao or both are not running with root priviledges, and that this should be fixed.
Firstly, you can safely ignore this message with any modern kernel. All you need is having your user at the "optical" group (might also be called "cdrom" or whatever your distro scripts wish).
And anyway, 'fixing' the above files' permissions is easily done via

kdesu k3bsetup2

On some distros k3b is build without the k3bsetup module, because the package maintainers think it's not needed, or that it's too intrusive. In that case you need to fix the permissions manually, but as I've said before you can safely ignore the message about cdrecord not running suid root.
You have also ignored it, because you falsely translated it as a hint of running the whole program as root. Please read again the warning more carefully.

This post has been edited by scarecrow: 05 May 2007 - 08:25 PM

[zibi1981]

diehl, on May 5 2007, 02:40 PM, said:

I just upgraded from 2007.0 to 2007.1 and now k3b says it should be run with "root privileges". I do not know what k3b wants me to do. I tried activating the suid bit on k3b (chmod +s /usr/bin/k3b) but then k3b will not run at all (as an ordinary user). I suppose I could run k3b from root, but this is not convenient and generates many warnings. Just what "root' privileges does k3b want?

You can also type in console as root

chmod 4711 /usr/bin/cdrecord

to give cdrecord privileges it requires, and avoid the warning message.

[neddie]

Thanks, that's cool! :thumbs:
Better than ignoring the warning message, I think! :D
Out of interest, what does 4711 mean? And how does that let a normal user run something with root privileges?

[zibi1981]

Nice to hear I could be helpful :D As for the explanation, You can read it all here i.e.

In short there are two (or maybe three) ways of changing privileges on Linux, at least as far as I know. One of them, and preferred according to many users, is by using digits to describe rights for groups and users. Conventionally these numbers stand for permissions to:
4 - read
2 - write
1 - execute
and all combinations of them:
7 (4+2+1) - read + write + execute
6 (4 + 2) - read + write
5 (4 + 1) - read + execute
3 (2 + 1) - write + execute

So let's take a closer look to chmod 711 (...) (I've knowingly omitted the number "4", and You'll see why I did so soon).

The order of these numbers is predetermined: first stands for the owner of the file, second for the group to which the owner belongs to, and third for all others.
There are also special bits, which can be adjusted. This is what the first number in chmod 4711 stands for. There are UID and GID and so called "sticky bit":
1 - "sticky bit"
2 - means setguid
4 - means setuid
and, as above:
3 - "sticky bit" + setgid
5 - "sticky bit" + seruid
6 - setgid + setuid
7 - "sticky bit" + setgid + setuid

Conclusion:

chmod 4711 /usr/bin/cdrecord

means that user (You) can read, write (make changes) and execute file cdrecord, and that cdrecord has setuid with all consequences.
There're also other ways to describe privileges on Linux, using letters:

Quote

r - read access
w - write access
x - execute access (also access to go into folder, in case chmod refers to a folder)
u - setuid
g - setgid
t - "sticky bit"

and this is what you see most often when You tape in console

[zibi1981@localhost bin]$ ls -al
(...)lrwxrwxrwx  1 root root		  26 kwi 21 12:43 cdrecord -> /etc/alternatives/cdrecord*(...)

rwx - read + write + execute access to that file. The "l" before that means "link".

Hope I helped a bit ;)

This post has been edited by zibi1981: 06 May 2007 - 08:54 AM

[neddie]

Thanks, I understood the 711 bit, just never used the setuid bit before. Have to look that up :)
Thanks for the info!

Just one small correction- I (as a normal user) don't get the "7" privileges because I'm not the owner of the file, I just get the "1" (execute only). The executable belongs to root and the cdwriter group.

[zibi1981]

neddie, on May 6 2007, 12:36 PM, said:

Thanks, I understood the 711 bit, just never used the setuid bit before. Have to look that up :)
Thanks for the info!

Just one small correction- I (as a normal user) don't get the "7" privileges because I'm not the owner of the file, I just get the "1" (execute only). The executable belongs to root and the cdwriter group.

Thanks for the correction ;) Hope that my post will help someone to understand a bit more :P

[teledyn]

Before you leap into this advice, be aware that setting cdrecord suid=0 can give unauthorized users root access to your machine -- before you do this, check a Google for the security implications for setting cdrecord as root