(*** This bug was imported into bugs.kde.org ***) Package: kdm Version: KDE 2.2.1 Severity: wishlist Installed from: SuSE RPMs Compiler: Not Specified OS: Not Specified OS/Compiler notes: Not Specified 1) I would like to see some features that would be useful for use in a mixed Windows/Linux networked environment. I run a number of Windows clients off a Linux server running Samba. The Windows clients use Samba for authentication and in addition to mounting a number of SMB shares from the server on login they also store the user desktop background and user.dat files storing menus on the server. This gives the user a roaming profile so the Windows desktop including any files copied to the desktop and the users menu settings go with the user when he logs onto another machine. I am going to upgrade the server and add X-Terminals and add Cygwin/Xfree86 to all the Windows clients to allow them to also function as X-Terminals. It would be really neat if KDM running on the X-Terminals and Linux workstations could automatically mount the same Samba shares as the Windows clients on logon and unmount them on logoff. This can be done by running smbmount as root using DisplayManager.DISPLAY.startup and DisplayManager.DISPLAY.reset in xdm-config. In order to supply the password the Linux password could also be used for the SMB shares if the Windows and Unix passwords are syncronized or KDM could prompt for an additional Windows/SMB password if not. The shares to mount and SMB password prompt option would be picked up from a config file. This feature could also be extended to allow mounting network block devices (eg. for mounting and accessing CDROMs on X-Terminals) using X-Cookie authentication and/or checking a list of permitted host(X-Terminal)-user combinations. I have tried network block device mounting on X-Terminals a while back and they worked well except for the fact that if an X-Terminal was switched off with the NBD mounted on the server the kernel process locked up and couldn't be killed. I believe this has now changed as the relevant code has been moved to user space. Another useful feature would be to allow sharing of the Windows desktop on the server with the KDE desktop. This could be done if KDE could specify another local directory (the directory on the server exported by Samba to the Windows client if on the same server) or SMB share or nfs exported directory as the KDE desktop. In addition to prevent Windows shortcuts on the desktop from appearing on the KDE desktop and vice versa KDE should hide Windows shortcuts (*.lnk) in the Desktop directory as default and the KDE shortcuts created on the desktop should not be written the alternative location desktop directory but should go to the ~/KDesktop directory which is merged with the alternative location desktop directory. This feature will also make it possible to have a user roaming desktop with Linux KDE workstations. 2) I would like to be able to run KDE on a remote machine using ssh with X forwarding (A KDE session in a separate window not a single KDE app). I can use something like: Xnest :1 -query 192.168.9.1 - terminate -depth 16 -geometry 800x600 to connect using xdm but this is not encrypted. I can use something like this with icewm: ssh 192.168.9.1 Xnest :1 & icewm -display :1 but startkde has a problem I think with sound resources. Is there a way ok getting KDE to run complete remote sessions under ssh. This would be really useful. (Submitted via bugs.kde.org)
as discussed with the submitter, the stuff boils down to passing authentication information to the Xstartup script. a pipe seems the correct solution here. an environment variable could be also secure enough, as one cannot look into the environment of foreign processes. anyway, on pam-enabled systems using specialized modules is the right solution.
*** Bug 59810 has been marked as a duplicate of this bug. ***
*** Bug 191622 has been marked as a duplicate of this bug. ***
KDM is unmaintained and not used in KDE Plasma 5. SDDM is the login manager used in KDE Plasma 5. If you still have this same issue with SDDM, please file an issue on the SDDM bugtracker (after doing a search for existing issues first!): https://github.com/sddm/sddm/issues/