Description of problem: Login with normal user account, switch user - choose other get dropped into gdm ( graphical glitches in between ), See my normal user account is "currently logged in" Choose other.. Type root and root password.. Log in as root Go back to switch-user.. Choose my normal account Log into that one. Go back to switch-user and am gonna choose root not available.. choose other get dropped to gdm type root and get dropped to my normal account.. ( root already logged in ) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. The above 2. 3. Actual results: Other cant map to "other/root/usernames typed in the field" logged in users.. Expected results: Been able to switch back to root so in fact I should be given three choses after login in as root root [x], my user/display name and other, and if I switch back to my user account and use swich-user my user/display name grayed out with [x], root and other should be shown... Additional info: This all has to do with that "other" does not seem to be able to map back/store somehow the username that is typed in the username field. This "other" makes no sense.. if it sole purpose is to allow root to be logged in it should be given more descriptive name Administrator/Superuser or something similar, which of course may lead to the root account being the only account being used by users. The other ( and possible better ) way is to remove the "other" all together and direct user to boot up in runlevel 3 and run gdm or startx etc. from the cli.
The purpose of Other is to handle large deployments where you have thousands of accounts in a directory service - those won't show up in the user list by default. Only local accounts (as in user accounts in /etc/passwd) and people who logged into the machine before are shown.
Ok so this is not just being deployed for root.. A) "Other" ( there must be better naming for this ) still needs to remember the entered username.. B) This *feature* needs to be off in default installation of Fedora or at least you need to be able to enable/disable "others" ( This will just confuse the home desktop users if left on) C) When users are switching they have to be able to choose "logout". On numerous times I have had to remind students of the importance of having to log out of their lap computers and in this case they would just switch user and leave and then next time they try to log in the could not because they would be still logged in, in lab a computer b.. then it's the question of when a switch user logs out of their computer "switch users applet" would fall back to the last still logged in user ( if it's not that user he would use switch-user if it is him, he would just type inn his password ) not GDM Is there´s any need for the extra step to be dropped to GDM and then click logged in user?. And another thing how many users are being expecting to be logged in at the same time 2 5 10 ???
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Is there any way to switch back to the conventional "username and password input boxes"? I consider it to be a security weakness to display the user list by default. Moreover, on my laptop for some reason the pre-selected user is not me, but some account which has logged in to that computer maybe year ago. In our computer lab, we have about ~2200 user accounts, and users logging on random machine. It does not make any sense to display only users who logged in to this computer in the past. It would probably be a large (100ish) subset of the accounts, probably bearing no relation to the person who will try to log in next. For me, it looks like the new gdm was rewritten with only small subset of use cases in mind.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.