Hi, I'll take the opportunity to add also 2 comments about lxdm.
I saw that lxdm is now tied to lxsession for user management. It's interesting for LXDE users, but for people using XFCE for example, it's not really nice because XFCE have already a session manager. If it's possible, I think it should be generic enough to work with all session manager. I also met an Ubuntu developers which began to work on a lightweight display manager. It's not finished, but I think some code could be shared : https://code.edge.launchpad.net/~robert-ancell/lightdm/trunk Regards, Julien Lavergne Le jeudi 10 juin 2010 à 20:41 +0200, Guido Berhoerster a écrit : > 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. > ------------------------------------------------------------------------------ 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
