Hello, as discussed on IRC I'll list of issues found the current development version of lxdm.
The most serious problem is the new signal handling code. Although it is somewhat an improvement over the previously completely broken approach of cleaning up from within the signal handler with lots of non-async safe code, it has several vulnerabilities primarily related to the usage of sockets for signal handling and communicating between the greeter and daemon. Firstly, the socket is created in /tmp with a well known name allowing for a simple DOS attack, any user can just mkdir /tmp/lxdm.sock and lxdm won't start any more. Secondly, it does try to unlink before binding the socket which leads to a race condition creating another possibility for DOS attacks. Thirdly, the socket is created world writable so any user can just delete it anyway. Avoiding this is Unix system programming 101 so my only suggestion (as I have stated before) is to use an anonymous pipe for signal handling (i.e. the self-pipe trick) and get rid of the socket altogether. For IPC there are better methods such as DBus. While I acknowledge that the code is under development, stuff like this should IMO never go into a public repository. The new signal handling code has also introduced a new problem with spawning the X server, I havent looked at it closely, but what happens is that when the Xserver fails, lxdm seems to get stuck in a infinite loop which cannot even be interrupted through a SIGTERM or SIGINT. Another rarther annoying problem is that lxdm currently does not redirect stderr/stdout so that spawned programs such a the X server spew their output to the console, such output should go to a separate logfile. Login/logut scripts are currently rather useless because they are called without USER/LOGNAME, HOME, and SHELL in the environment (as GDM/KDM do) it is thus impossible to do anything that requires kwnoledge of the user logging in or out such as adding/removing utmp from these scripts. Fixing this should be easy with the new session object. There is lots of generic code which can and should be replaced by glib functions, that e.g. includes logging (glib includes logging functionality allowing for different log levels and debug output) and the rather bizarre way of commandline option parsing. Some amount of code handling sockets (if this has to be kept) can also be replaced with GIO functionality. Most of the paths are hardcoded and should probably be replaced with proper macros making the life of packagers easier. That's all for now, there are probably other issues not in the above list. -- Guido Berhoerster ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
