There are two sides doing locking: lightdm itself, and the individual greeters.
Greeters might typically use fancy UI libraries like Gtk+, Qt etc., where it will be hard to clear all password bits; e.g. text input might be passed around multiple layers. Lightdm will typically pass messages to PAM and get some messages back, not necessarily knowing which ones are passwords. Now the greeter is usually not running when the desktop is running, so I guess it's not too bad to mlockall() that process since that memory will be freed up for the desktop after a successful login. Concerning lightdm, we could either scrub all PAM messages after we're done with them, but I'm not sure whether the PAM stack is itself careful about handling not writing passwords to swap and using mlock; another approach would be to implement the lightdm protocol with the greeter in a separate program which would also do PAM, but keep the other common lightdm features separate so that mlocking just the new helper would mlock less memory. NB1: I was hoping that we were locking a lot of shared read-only pages, but "pmap" on the lightdm process shows that rw pages are mainly from shared libraries: pmap 1586 | grep rw 0000000000627000 4K rw--- /usr/sbin/lightdm 000000000255a000 284K rw--- [ anon ] 00007f69a8000000 2584K rw--- [ anon ] 00007f69b0000000 132K rw--- [ anon ] 00007f69b6bd7000 4K rw--- /lib/x86_64-linux-gnu/libnss_files-2.16.so 00007f69b6de3000 4K rw--- /lib/x86_64-linux-gnu/libnss_nis-2.16.so 00007f69b6ffb000 4K rw--- /lib/x86_64-linux-gnu/libnsl-2.16.so 00007f69b6ffc000 8K rw--- [ anon ] 00007f69b6fff000 8192K rw--- [ anon ] 00007f69b7800000 8192K rw--- [ anon ] 00007f69b8000000 132K rw--- [ anon ] 00007f69bc369000 4K rw--- /lib/x86_64-linux-gnu/libnss_compat-2.16.so 00007f69bc36b000 8192K rw--- [ anon ] 00007f69bcd6e000 4K rw--- /lib/x86_64-linux-gnu/libdl-2.16.so 00007f69bcf72000 4K rw--- /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 00007f69bd17b000 4K rw--- /lib/x86_64-linux-gnu/librt-2.16.so 00007f69bd3b9000 4K rw--- /lib/x86_64-linux-gnu/libpcre.so.3.13.1 00007f69bd5c1000 4K rw--- /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0 00007f69bd7d9000 4K rw--- /lib/x86_64-linux-gnu/libresolv-2.16.so 00007f69bd7da000 8K rw--- [ anon ] 00007f69bd9f9000 4K rw--- /lib/x86_64-linux-gnu/libselinux.so.1 00007f69bd9fa000 4K rw--- [ anon ] 00007f69bdc11000 4K rw--- /lib/x86_64-linux-gnu/libz.so.1.2.7 00007f69bde15000 4K rw--- /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.3504.0 00007f69be1d1000 8K rw--- /lib/x86_64-linux-gnu/libc-2.16.so 00007f69be1d3000 20K rw--- [ anon ] 00007f69be3f0000 4K rw--- /lib/x86_64-linux-gnu/libpthread-2.16.so 00007f69be3f1000 16K rw--- [ anon ] 00007f69be602000 4K rw--- /lib/x86_64-linux-gnu/libpam.so.0.83.0 00007f69be820000 4K rw--- /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 00007f69bea26000 4K rw--- /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 00007f69bed20000 4K rw--- /lib/x86_64-linux-gnu/libglib-2.0.so.0.3504.0 00007f69bed21000 4K rw--- [ anon ] 00007f69bef72000 4K rw--- /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3504.0 00007f69bf2d3000 8K rw--- /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3504.0 00007f69bf2d5000 8K rw--- [ anon ] 00007f69bf4c9000 36K rw--- [ anon ] 00007f69bf4f7000 8K rw--- [ anon ] 00007f69bf4fa000 8K rw--- /lib/x86_64-linux-gnu/ld-2.16.so 00007fffeb585000 132K rw--- [ stack ] NB2: the lightdm --session-child process isn't mlock-ed; it would seem this is ok on Linux as memory isn't reused when exec-ing into it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1074279 Title: lightdm uses ~30 Mb of RAM To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1074279/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
