K3b needs cdrecord and cdrdao to be given root permission. This can usually be done by clicking on k3bsetup. However, k3bsetup is only available when k3b is emerged with the kde flag, which will include the installation of kdesu which amounts to more than 23MB. I set the permission manually instead:
chown root:cdrom /usr/bin/cdrdao
chown root:cdrom /usr/bin/cdrecord
chmod 4755 /usr/bin/cdrdao
chmod 4755 /usr/bin/cdrecord
The first digit (4) after chmod selects the set-user-ID. What in the world does that mean? I found this explanation which I think is pretty clear:
SUID stands for Set User ID. This means that if the SUID bit is set for any application then your user ID would be set as that of the owner of application/file rather than the current user, while running that application. That means in case I have an application whose owner is ' root ' and it has its SUID bit set, then when I run this application as a normal user, that application would still run as root. Since the SUID bit tells Linux that the the User ID root is set for this application and whenever this application executes it must execute as if root was executing it (since root owns this file).
Just like SUID, setting the SGID bit for a file sets your group ID to the file's group while the file is executing. IT is really useful in case you have a real multi-user setup where users access each others files. As a single homeuser I haven't really found a lot of use for SGID. But the basic concept is the same as the SUID, the files whose SGID bit are set would be used as if they belong to that group rather than to that user alone.
chown root:cdrom /usr/bin/cdrdao
chown root:cdrom /usr/bin/cdrecord
chmod 4755 /usr/bin/cdrdao
chmod 4755 /usr/bin/cdrecord
The first digit (4) after chmod selects the set-user-ID. What in the world does that mean? I found this explanation which I think is pretty clear:
SUID stands for Set User ID. This means that if the SUID bit is set for any application then your user ID would be set as that of the owner of application/file rather than the current user, while running that application. That means in case I have an application whose owner is ' root ' and it has its SUID bit set, then when I run this application as a normal user, that application would still run as root. Since the SUID bit tells Linux that the the User ID root is set for this application and whenever this application executes it must execute as if root was executing it (since root owns this file).
Just like SUID, setting the SGID bit for a file sets your group ID to the file's group while the file is executing. IT is really useful in case you have a real multi-user setup where users access each others files. As a single homeuser I haven't really found a lot of use for SGID. But the basic concept is the same as the SUID, the files whose SGID bit are set would be used as if they belong to that group rather than to that user alone.
No comments:
Post a Comment