Version: (using KDE KDE 3.2.2) The button could start "kdesu kuser" for example/default. This is to enhance usabilty by providing the option to change choices at the same place where the decision is needed. This is to facilitate the use of different user IDs within one session on a graphical UI basis, which should be handled by the graphical DE in a standard way so applications don't need to implement own user authentication etc. See other related wishlist items and the discussions on http://lists.debian.org/debian-desktop/2004/05/msg00004.html and http://freedesktop.org/pipermail/xdg/2004-March/003529.html
Can you provide a use case that shows the benefits of having such button in kdesu?
Think of small office / home (office) scenario where (one) user is also admin for most cases. The ideas in the threads mentioned above try to simplify an adequate use of system security features in graphical environments. It was envisioned to help (small)part-time admins to seal off programs or rather the data of those programs. Example: A trusted Family PC (trusted by the family that is) defaults to have one shared local auto-login access to a "guest" account. Not much need for system administration. All what would be necessary to seal off just the accounting data for example though, could be to do a right click "Run as user ..." (#81208) on the app. The user could then be presented with kdesu, this time prompting him with both, a user and a password field. Possibly with a drop down box to choose a user on smaller systems. At this point providing a button to edit the list of users may be a great help for a new user/admin to add a new user. He would not have to know a separate admin point of entry or the mental model of unix user IDs. It may also seem more intuitive because it's more object or context oriented, you see the list of users, you may want to edit it. When the app is then run with a different user ID and $HOME the data is sealed off appropriately without needing any "dirty" password hacks etc. on the app side, this is especially true when apps want to implement group access functions. Related: #81208 support right-click "start as..." different user for icons and menues #81209 prompt for password instead of failing if filepermissions are not sufficient #81210 kdesu window should offer option (button) to start user management
this goes into the direction of sandboxing and virtualization. other projects have taken up that task; whatever we'd produce here would be inferior.
Sandboxing (permissions), multitasking or virtualisation are (operating) system issues. Providing the buttons (support) is merely implementing a usefull GUI to existing system security features. By now all Desktop OSes have support for things like user permissions and dynamic switching, and MS does have GUI support for it, but the free DEs seem to neglect making system security features usable. Systems with the "sandbox -X" command available do allow keybord/mouse sniffing security, however even without it there is file access and process security. This and the related reports just call for some small UI improvemnts that should make the existing system features usable.