The /etc/init.d/gkrellmd script that comes with the gkrellm-2.1.7a ebuild runs as root by default. There are gkrellmd options to switch the effective user/group when it starts, which would prevent a possible daemon exploit from giving remote root privileges. The gkrellmd switches are --user <user> and --group <group>. Maybe the ebuild should add a gkrellm user/group and the init script use the switches to ensure that the daemon runs only with those privs? This will unfortunately break gkrellmd on systems running kernels with restricted /proc access, ala grsec. Maybe the gkrellm user needs adding to the `can access /proc unrestricted' group for such kernels?
you know, I remembered reading that in the README when I updated the package, and then forgot about it at some point before putting it into portage. I'll take a look at this now.
method -- comments on the grsec thingy?
In the GRSecurity configuration in the kernel config: Filesystem Protections ->Proc Restrictions If proc restrictions are enabled, then: ->->Allow special group ->->->GID for special group Make sure that gkrellmd runs as a user who is in the GID specified. Having a quick look at my .config, the following options appear to be relevant: CONFIG_GRKERNSEC=y (enabled grsec) CONFIG_GRKERNSEC_PROC=y (enable proc restrictions) CONFIG_GRKERNSEC_PROC_USERGROUP=y CONFIG_GRKERNSEC_PROC_GID=<GID> Checking /usr/src/linux/.config (or preferably /proc/config if present) for _PROC=y, then recommend adding _USERGROUP and _GID if not already enabled. If they are enabled, recommend adding the gkrellmd to the specified group. This should get around the grsec problem, providing people are willing to trust gkrellmd with this information. Seeing as the other alternative is running is as root though... :)
well, all you gotta do is edit your /etc/gkrellmd.conf file and uncomment the appropriate lines. In other words, it works with 2.1.8a; not sure what else you would want me to do with it.
