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 Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1074279 Title: lightdm uses ~30 Mb of RAM Status in Light Display Manager: Triaged Status in “lightdm” package in Ubuntu: Confirmed Status in “lightdm” source package in Raring: Confirmed Bug description: After loging in into the XCFE environment, I open a terminal and perform a top. If I sort the processes by decreasing resident memory, I see that lightdm requires 32MB of memory, that is more than X ! Since lightdm just sleeps after login in, I think it is wasting memory. Could it possibly load/unload features dynamically as gdm already did (many small processes which were launched when a feature was required) ? ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: lightdm 1.4.0-0ubuntu2 ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5 Uname: Linux 3.5.0-17-generic x86_64 ApportVersion: 2.6.1-0ubuntu6 Architecture: amd64 Date: Fri Nov 2 10:19:19 2012 InstallationDate: Installed on 2012-10-20 (12 days ago) InstallationMedia: Xubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.1) MarkForUpload: True SourcePackage: lightdm UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1074279/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
