2010/6/11 Guido Berhoerster <[email protected]>
>
> 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.
>
maybe move the lxdm.sock to /var/run path helpful? or just use anonymous
socket?
>
> Thirdly, the socket is created world writable so any user can
> just delete it anyway.
>
> I want to make it anyone can writable, so make it anonymous too ? or maybe
other method
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.
>
> use pipe will take two file descriptors, as glib in child watch code
already introduce the two pipe and a
thread, I don't think they are good.
I'don want to depend on dbus, the lxdm's goal is to work with no dependency
not necceary.
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.
>
> the problem is in old lxdm too, but the signal handler code deal it, it
will fixed by make some code into glib loop.
> 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
>
------------------------------------------------------------------------------
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
