Bugzilla – Bug 64
GDM doesn't accept empty passwords, but setup does
Last modified: 2009-10-15 01:33:43 UTC
You need to log in before you can comment on or make changes to this bug.
I installed Project Indiana Developer Preview with no user information entered into the installer. So no normal user, and no root password. But the login screen doesn't accept an empty password for root, when it should.
Workaround: Press "e" in grub twice to edit the boot entry. Add -s to the end of it and boot to that. Log in as root and enter passwd to change the password to something other than nothing. Restart and the -s is gone automatically from the boot entry. Boot normally and log in with the new password.
(In reply to comment #1) > Workaround: Press "e" in grub twice to edit the boot entry. Add -s to the end > of it and boot to that. Log in as root and enter passwd to change the > password to something other than nothing. > > Restart and the -s is gone automatically from the boot entry. Boot normally > and log in with the new password. Not sure what is going on with this part: Restart and the -s is gone automatically from the boot entry. Obviously grub acts in a way that I don't fully understand :) I also don't see how or why it (grub) knows to not even give you the option to boot from the CD again once the hard disk version is installed.
Just a comment that edits you make interactively in GRUB are temporary, only effective for that invocation of GRUB. In order to make persistent edits, you have to edit /zpl_slim/boot/grub/menu.lst. The boot ordering is entirely dependent on your PC's BIOS settings.
*** Bug 422 has been marked as a duplicate of this bug. ***
The GDM configuration has a PasswordRequired configuration option in the [security] section. Is this set to true by default? If so, does changing it to false make a difference? Also make sure that the [security] AllowRoot configuration option is true. Could you try turning on Enable=true in the [debug] section of the configuration file. Then restart GDM and recreate the problem of being unable to login vai the root user with no password. Then share with me the gdm-related output that gets sent to your syslog file (/var/adm/messages). This will help me to debug. I wonder if this is a GDM bug or a PAM bug. Note that PAM is the code that actually handles the authentication.
Steps to reproduce: Boot from install CD, start installation, proceed to step 5 (users), type in name and login name, but leave password empty (installer allows this for both root and regular user). Finish installation, reboot and type login name into GDM login prompt. Press enter. Actual result: password prompt appears and "OK" button is disabled until you type in something in password prompt. Expected Results: either 1. OK available with empty password field, 2. no password prompt for users with empty passwords 3. disallow passwordless users in installer Additional info: it's not clear how to deal with this situation-- some decision should be made either to fix GDM or modify installer. In newer Linux distros GDM follows second way (no password prompt at all for passwordless user) Build date and Platform: OpenSolaris RC0, Apr 07, 2008
Adding PasswordRequired=false to /etc/X11/gdm/custom.conf fixes this problem. It's a trivial fix and something important to have sync with the installer or will confuse users.
I thought changing PasswordRequired should fix this (note my comment #5). I agree that changing the default value to false is a trivial change, and the best way to fix this issue.
Created an attachment (id=211) [details] it's possible to isntall OS without user and root informations
Created an attachment (id=212) [details] not fixed yet! RC1
rising priority to P2 because this BUG provides security hole.
*** Bug 1475 has been marked as a duplicate of this bug. ***
This is not a stopper for 2008.05 so reducing the Severity field.
This should be fixed for the first release. I just installed the latest RC and used all the installer defaults, and now the os is broken. Can't log in as anything. I won't change the priority on this, but someone else should. You cannot rightly ship an OS when the default install prevents the OS from working.
However by default, a user password is requested. Do you believe most users will be installing their accounts without setting a password?
Nothing changed in RC3.
(In reply to comment #15) > However by default, a user password is requested. Do you believe most users > will be installing their accounts without setting a password? I didn't notice such a thing. I just saw a bunch of prompts that I didn't want to fill in, and clicking NEXT worked so obviously I didn't need to fill them in. This is me simulating normal people. And my answer to your question is "I think many people will want to skip the two users and two passwords because they don't want two users and two passwords" I'll elaborate below. This is a desktop OS so pretend you are a Windows XP user with a Dell computer :) Desktop users don't know what root is... Don't know what a superuser/root role is. Don't know the difference between "user" and "root" is, (not that anyone would, is it explicitly stated that one is a role that you cannot log into, and one is a desktop user? The first time I ran into this bug I made a root password but no user). The multiple users thing combined with the optionality of them seems like a bear trap to me. Customer + bear trap = ????? The OS use case for a typical desktop user is simple: Turn computer on, wait, double-click web browser icon. Most people don't even know that a password was involved in this process, if it was. The installer has to facilitate this end goal, if that is your goal. Now if you don't want to do things the way they have been done in the past, that is fine. But the users will still do things the old way, and still expect things to work the old way. And so they will walk into the bear trap until it is removed :) The fix I'd be fine with is just let root log into the desktop with no password. But there are big picture repercussions to such a decision that would require discussion. If that wasn't an option, the alternatives are there, like don't let the installer end without two passwords and a user name entered, with short explanations for why this is happening. (Note in this case that people will try to use the same password for root and their user name, bypassing the alleged security that would be pushed on them :)) This is all assuming I'm trying to make a grade A product right off the line. If: - you don't think important desktop users will be trying this first release, or - you don't think significant damage will be done if new users have a bad experience, or - you think all new users will be experienced unix/linux people who will have no problem or will come back later no matter what happens, or - etc Then that produces a different set of requirements, and I might be content to ship it with this bug present.
As much as I'd like to address this bug for the initial release, I still don't believe we should stop the release in order to fix it. Hopefully this can be fixed in a near build and the revised package pushed to pkg.opensolaris.org.
*** Bug 1901 has been marked as a duplicate of this bug. ***
This is still the case in build 100. Note that while the user is able to authenticate via login or su without a password, the default system configuration considers the non-password to be "expired" and immediately requests that the user provide one. So in addition to fixing GDM to behave properly, the system's configuration also needs to be changed to permit users to not have passwords. Incidentally, GDM's behavior should really reflect the questions PAM is asking. Even if GDM elects to enforce an additional password policy, presenting a password dialog when the system isn't asking for a password simply doesn't make sense.
*** Bug 4740 has been marked as a duplicate of this bug. ***
*** Bug 4748 has been marked as a duplicate of this bug. ***
*** Bug 4757 has been marked as a duplicate of this bug. ***
*** Bug 4763 has been marked as a duplicate of this bug. ***
I comment #7, Clay suggests that setting PasswordRequired=false in /etc/X11/gdm/custom.conf fixes the problem. I am confused. Note that GDM should be using the default value of false for PasswordRequired to begin with. What is the value of PasswordRequired in the "[security]" section of the file /usr/share/gdm/defaults.conf? It should be as follows: #PasswordRequired=false How does GDM behave when you remove the comment character (#) from the beginning of the line, and make sure that "PasswordRequired=false" isn't being set in the /etc/X11/gdm/custom.conf file? At any rate, note that GDM should ignore the PasswordRequired setting if the /etc/default/login file contains the "PASSREQ=[YES|NO]" value. The file /etc/default/login should take precedence over the GDM configuration value for PasswordRequired. Does just making sure that /etc/default/login contains PASSREQ=NO fix the problem as well? Dave Powell, in comment #20 you suggest that GDM is not reflecting the questions PAM is asking. Looking at the GDM code, it only asks the user to try entering a new password if pam_acct_mgmt returns PAM_NEW_AUTHTOK_REQD. Overall GDM is already designed to just blindly do whatever PAM tells it to do. Perhaps there is something wrong with the PAM stack which GDM is using which is causing pam_acct_mgmt to not behave properly when being used with GDM?
Except that gdm doesn't actually do that. If I try to log in as a user that doesn't have a password, it doesn't ask for a new password. It simply asks for a "Password:", and regardless of what I enter I get the "Invalid username or password." error.
Dave, if "PasswordRequired" gets set, then GDM passes PAM_DISALLOW_NULL_AUTHTOK as the 2nd argument to pam_authenticate. So this is likely what is disallowing this from working. Comment #7 seems to confirm this, but I'm a bit confused why setting the value in custom.conf would change things since the default value in /usr/share/gdm/defaults.conf should have already been "false". What is the default value in your /usr/share/gdm/defaults.conf file? If I am correct and the value in /etc/default/login is causing the issue, then it should be fixed there. Note GDM defers to the value here, and the GDM configuration should be ignored if this file contains a PASSREQ line. I'm wondering if there might be an odd bug where if the value is "false" in /usr/share/gdm/defaults.conf, "true" in /etc/default/login, and "false" in /etc/X11/gdm/custom.conf that it might be getting set to "false" incorrectly. Perhaps you could clarify? Thanks.
During the install, I gave a password to root but did not create an additional user. Creating a user seemed to be an optional step so I did not do it. After rebooting the system, I cannot log into it. Because root is now a role, trying to login as root gives the message of "Roles can only assumed by authorized users." Why isn't creating a userid with a password mandatory? If you don't do it, you can't login. I think this should be release noted.
Regarding #28, PasswordRequired isn't set in any GDM configuration file. (It is commented out in defaults.conf). PASSREQ is set to yes in /etc/default/login. 'su' will permit login if it is unset, and will prompt for a new password when it is set. GDM will prompt "Password:" regardless of its setting. I don't understand why this sort of policy would be implemented in GDM (at least not on Solaris). But ignoring that for the moment, if GDM does implement a policy that requires a password, it should fail if no password is required by PAM, not prompt the user for a password that doesn't exist.
Regarding #29, If you don't create an initial user, the installer shouldn't be making root a role. If it is, that's a whole different bug.
(In reply to comment #31) > Regarding #29, > > If you don't create an initial user, the installer shouldn't be > making root a role. If it is, that's a whole different bug. Whoa. I haven't been following this, but I thought that was implicit in this bug discussion.
Any update on this old issue? I have hit into this issue myself and one more guy from Prague did as well. Thanks.
Setting PASSREQ to any value other than "YES" (case insensitive) should fix this problem. If this doesn't fix the problem, then this is a bug with GDM. Let me know if this is the case. I think you want to modify the default setting of PASSREQ in /etc/default/login if you want passwords to not be required.
This really needs to be fixed. I just installed OpenSolaris in a virtual machine just to check it out, so it was entirely reasonable to not set any passwords. And, well, that's what I got. Sure, it was easy to boot into the single user mode and just set the password, but it's not exactly a good thing to have a bug like that greet a new user at the door. Especially when the fix is so trivially easy, someone just has to do it.
This is not a desktop bug. It is a bug with the default settings in the /etc/default/login file.
Is the system broken here or what? People have been passing the buck on this for more than a year. I hope it isn't as bad in other bug reports.
David Comay and Dave Minier, I believe that to fix this bug it is only necessary to change the default configuration of the /etc/default/login file so that the PASSREQ=NO setting is defined. Would this be an appropriate change to make via the SUNWfixes packages or something? I suspect that we would need to modify this OpenSolaris only, since getting a change with security ramifications like this into Nevada would likely take some time. However, for the purposes of a liveCD, making this change to OpenSolaris would make a lot of sense. Who is the right person to take over fixing this file? I am guessing someone else is more experienced with making OpenSolaris specific configuration changes like this.
Can this fix go into the 09.06 release?
The only correct fix is to have the installer *not* accept empty passwords.
> The only correct fix is to have the installer *not* accept empty passwords. IMO you shouldn't force that on people. Especially in this age when I can have 10 opensolaris virtual machines I need to log into for testing. Obviously this needs to be reconciled. But my vote is for allowing no passwords. By default I lean toward allowing user the freedom to cook their food the way they want. In this case though I actually see a situation where this feature is good.
(In reply to comment #41) > > The only correct fix is to have the installer *not* accept empty passwords. > > IMO you shouldn't force that on people. Especially in this age when I can have > 10 opensolaris virtual machines I need to log into for testing. > > Obviously this needs to be reconciled. But my vote is for allowing no > passwords. > > By default I lean toward allowing user the freedom to cook their food the way > they want. In this case though I actually see a situation where this feature > is good. The issue is not whether empty passwords should be allowed. The issues is how they should be allowed. For many years Solaris -- from which OpenSolaris is derived has had as a default to not allow empty passwords. GDM correctly interprets how OpenSolaris is configured. The issue is the installer is not correctly installing the system when given empty passwords. Options are to not accept empty passwords,to correctly configure the defaults of the system, or ... IMO, this "bug" is misclassified. No changes should be made to the default setting; no change should be made to GDM. Gary..
Then fix the installer, so that, when the user is trying to give it an empty password, it displays some big fat warning about the risks associated with configuring the system to allow user account with no password and asks for a confirmation, preferably twice, with the Yes/No buttons swapped.
Removing from blcoker list and reassining to install where it should be fixed. Note at this late stage this cannot be fixed for 2009.06. Thread from Brian Cameron and Niall Power > >>> the installer could just assume >>> that if the user entered an empty password, that they want the >>> /etc/default/login PASSREQ setting to be YES instead of NO, and >>> go ahead and make this change directly. This approach might be >>> more nice if we had a dialog that said something like "You have >>> requested an empty password. Are you sure? Selecting Yes will >>> change the Solaris configuration to allow empty passwords for >>> users. [Yes] [No]" >>> >>> I am cc:ing Niall since he is more involved with the installer, >>> and might be able to help with this bug? >> >> I prefer this approach personally. One person who commented >> on the bug as user "MC" made a good point about installing many >> instances in a virtualised setup where not having to set a password >> would be a nice feature to have. A simple warning to warn the user >> that their system will be insecure and then let them proceed if that's >> what they truly want. The installer already writes to the passwd and >> shadow passwd file to configure the account on the installed system >> so I think it would be appropriate for it to also modify >> /etc/default/login to set PASSREQ to "NO" if a blank password has >> been set. > > I am glad you agree that this bug should be fixed in the installer. > Is there any chance this could be fixed in the 09.06 release? This > bug is a real annoyance for some users and it would be great if we > could fix this. I think the work involved with checking if the > password is NULL, and then adding a dialog to confirm, and then > modifying the /etc/default/login to set PASSREQ to "NO" after > confirmation seems a small, low-risk, and reasonable feature to add. >
*** Bug 8812 has been marked as a duplicate of this bug. ***
This bug will actually get fixed indirectly by bug #1436. It's been decided to remove the entry of a root password, and to make entry of username/password mandatory. This new design will resolve any issues highlighted by this bug.
This bug is fixed indirectly because of fix for bug 1436. Now in the installer, root password is supplied at all, however the installer requires that both log-in name and password are supplied for the creation of a normal user. Thus the login screen (gdm), does not require amending as the normal user will always have a password.
Although fixing 1436 will make this issue go away for the GUI installer there are other installers. There are only two sure ways to fix this. One is to do what Brian suggests in an email in comment 44: "The installer already writes to the passwd and shadow passwd file to configure the account on the installed system so I think it would be appropriate for it to also modify /etc/default/login to set PASSREQ to "NO" if a blank password has been set." The other is for the installer to require a password if PASSREQ is "yes". In the latter case the distribution is setting the policy, at least until a user creates a password, installs, logs-in and changes it. In the former case the user sets the policy automatically when they install. I suggest the installers implement the former policy, i.e., set PASSREQ based on whether the user sets a root password or not.
(In reply to comment #48) > I suggest the installers implement the former policy, i.e., set PASSREQ based > on whether the user sets a root password or not. I think that is a bad idea. PASSREQ applies to all users, not only to the account used for installing the system. The default PASSREQ=YES has been ARCed (PSARC 2007/700), it is a standard policy that results in a more secure out-of-the-box system. If administrators are willing to lower the security of the system, /etc/default/login can be edited as a deliberate, well thought through action.
I think setting the root password *is* only done as a part of a well-thought-out decision. Protecting users who do this sort of thing does not seem necessary to me. So, it does make sense, I think, for the installer to set PASSREQ=yes if the user specifies a NULL root password. Doing so implies the user doesn't care about passwords.
(In reply to comment #50) > I think setting the root password *is* only done as a part of a > well-thought-out decision. Yes, but leaving it blank is usually part of a "hit-return-through-installation". Setting it is part of a different thought process than leaving it blank. > So, it does make sense, I think, for the installer to set PASSREQ=yes if the > user specifies a NULL root password. Doing so implies the user doesn't care > about passwords. And what if the administrator subsequently sets a password for root, after the initial, maybe of-line, configuration for the system is done? Do you suggest to automatically change PASSREQ to YES? Or leave the system with PASSREQ=NO without the administrator knowing about it? I'd suggest, that if you want to change the default, take it to ARC...
I think that if the user enters no password for the root account during interactive install time, that it would be best to pop up a dialog like this: You set an empty password for the root account. Would you like the system to allow users to login with an empty password? If you choose "No", then the root user will have an empty password but you will not be able to login as this user. If you choose "Cancel" you can return to the previous screen and specify a password. If you choose "Yes", and wish to revert this configuration later, then please refer to the PASSREQ section of the login(1) manpage for information about how to do this. [ Yes ] [ No ] [ Cancel ] Brian
> It's been decided to remove the entry of a root password, and to make entry of username/password mandatory. So the root password is forced to be nothing now, so root cannot log in? No root user by design. The management of rights in operating systems is confusing for me because everyone does something different. That this is changing in opensolaris just now tells me the direction of opensolaris is as confused as I am.. > Yes, but leaving it blank is usually part of a > "hit-return-through-installation". > Setting it is part of a different thought process than leaving it blank. Personally that wasn't the case for me. When I was installing this OS into a VM years ago (when I filed this bug), I wanted: one user to log in with administrator abilities no config file tweaking convenience I'm not an expert, but I wonder if this bug is really such a problem. The relevant installer screen is (or was) how the installer people wanted it, so why couldnt the operating system be fixed to work.