Using LTSP 4.1; ltspinfod version 0.1. If the lts.conf file has the ALLOW_SHUTDOWN option set to 'Y', then there is no restriction on who issues a shutdown or reboot command. That is, the commands could come from anywhere, whereas in our case we wish to restrict them to only come from a specific server (our LTSP server). Without this, there is nothing stopping anyone simply telnetting to an LTSP client on port 9200, and entering 'shutdown'. This will then shutdown the client. Obviously, this could become a serious DoS. We need to use the shutdown/reboot commands in order to control the LTSP clients for our purposes, but they must be restricted to our own server.
Created attachment 3798 [details] [review] Patch for run_ltspinfod file
Created attachment 3799 [details] [review] Patch for /usr/bin/ltspinfo command
Created attachment 3800 [details] [review] Patch for source file ltspinfod.c
I have worked on this problem for our site and this solution seems to work well. Attached are patches for the run_ltspinfod file, the ltspinfo command and the source ltspinfod.c. If the lts.conf file is left unmodified then the previous behaviour occurs. 1) I have created 2 additional variables for the lts.conf file: CMD_SERVER - this is a space-seperated list of server IP addresses. These servers may issue ltspinfo commands to the relevant client. CMD_SYS_ONLY - if this is set to 'Y', then only the shutdown/reboot commands are restricted to the above server list. All other commands are executed regardless of who sent them. This option has no effect if CMD_SERVER is not set. 2) The run_ltspinfod file has been modified to recognise the above options and call ltspinfod accordingly. 3) The ltspinfod program has 2 new options which are used by run_ltspinfod when necessary: '-f ipaddr ...' - this is the list of server IP addresses; ('f' for 'from') '-F' - this flag signals that only the shutdown/reboot commands are to be checked. The ltspinfod process will return to the sending server the message 'Access denied' if they are not allowed to send commands to the client. 4) The ltspinfo commands has been modified slightly to return an error message rather than just 'die'-ing. It was found that sometimes if access was denied then the network connection was closed before the message ('Connection reset by peer') was processed. As such ltspinfo just died (in the perl sense of 'die'). Since we use ltspinfo from a script, it was changed to return the actual error message rather than dying. Possible future change: Allow the use of DNS names rather than just IP addreses. Alternatively if tcp_wrappers is integrated into LTSP (with 4.1 it seems to be present in the LBE, but not by default available to clients) then it may be easier to just use that. John.
John Horne Do you still experience this issue with newer drivers ? Please check the status of your issue.
Sorry, but we haven't used LTSP for several years. I have no idea whether this is still a bug or not.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.