It allows screen blanking in user mode, when the "suid" USE flag is enabled. Here's the patch: --- /usr/portage/app-laptop/radeontool/radeontool-1.5.ebuild 2004-10-28 18:07:32.000000000 +0200 +++ radeontool-1.5.ebuild 2004-12-17 19:07:03.801228112 +0100 @@ -8,7 +8,7 @@ LICENSE="ZLIB" SLOT="0" KEYWORDS="x86 ~amd64" -IUSE="" +IUSE="suid" DEPEND="sys-apps/pciutils" src_compile() { @@ -19,3 +19,9 @@ dobin radeontool dodoc CHANGES } + +pkg_postinst() { + if use suid; then + chmod u+s ${ROOT}/usr/bin/radeontool + fi +}
please put patches as attachments. Also I think the suid should be set in src_install.
Why infest your system with another suid binary? Why not use 'sudo' for this?
Created attachment 46268 [details, diff] New patch for radeontool-1.5 Ok, I attached the new patch, which optionally sets SUID in src_install(). Note: The reason why I first did it in pkg_postinst(), is because app-crypt/gringotts does it this way.
Indeed, why not sudo ? Well there's the case when people launch radeontool from xscreensaver, to blank the LCD screen. In that case, the script (ie: lightwatch.pl) is launched with user priviledges..
WHy not use "xset dpms force off" for that? It works on my radeon card since I have Option "dpms" in my montior section in xorg.conf.
Well, I've just tried "/usr/X11R6/bin/xset dpms force off" -- the screen goes black, but the LCD backlight stays on. I do have the proper dpms line in xorg.conf's monitor section. When invoking "/usr/bin/radeontool light off", everything including the backlight, is powered off.
I will not enable SUID in the radeontool ebuild since sudo works just fine for this. Closing as WONTFIX.
Please have a look at comments #4 and #6 again - the reasons seem valid to me. Thanks
> Please have a look at comments #4 and #6 again - the reasons seem valid to me. Of course they seem valid to you - you wrote them. I see no reason to introduce yet another SUID binary in the system, if you feel otherwise you can change the binary to SUID on your system. This enhancement request is closed.
I think you should try to get that accepted by the author of the package.. if he agrees that his binary should be installed suid.. you have better chances to get it into portage. Or it enters portage automatically then with a version bump :)
Thanks to both for your prompt response.. I understand your security concerns about SUID executables, and I apologize for having insisted. The reason was, sudo can't help in non-interactive backlight powersaving situations. You gave me a good idea: I'll ask the author what better ways there could be. Thanks again