[ Prev ] [ Table of Contents ] [ Front Page ] [ FAQ ] [ Next ]


(?) The Answer Guy (!)


By James T. Dennis,
LinuxCare, http://www.linuxcare.com/


(?) Corel Linux and Blank Passwords

Repairing Lost and Broken Passwords: A Redux

From Charles Gratarolli on Mon, 15 May 2000

(?) Hi,

After a few crashes I managed to install a Corel Linux in my machine(Pemtium II 450, IDE Drive, 96 MB of memoy). When the system asked me for a login and password, it didn"t recognize and gave me the following messsage:

COREL LINUX 1.0(tty1)

Login:XXXXX(I gave it in the insyalation beggining) Password: Incorrect login

(!) This is fairly difficult to read and I'm not sure of the context. I think you are saying: "After I installed Corel Linux and rebooted the system, I tried to enter the same name and password at its login prompt that I had entered during the installation process." (I've only installed Corel Linux a couple of times I don't remember the exact sequence of installation dialogs).
Normally you'd have been prompted to create a password for 'root' (the system administration account) and you would have been offered a chance to create one or more user accounts --- which involve selecting at least a user name and initial password for each account. (Usually there's also a chance to fill in a full name, change the account's "home directory" and "login shell" settings, set the account's primarly group membership and possibly add that account to a list of other groups).
What happens if you use the name 'root' (all lower case, no capital letters) at the "Login:" prompt and enter your password for that account? (BTW: It's a good idea to keep those passwords different. It's a wretched idea to login as 'root' when you want to run "normal" applications like a web browser, mail program etc).

(?) I left the password blank, as was said in the manual

(!) Did the manual really suggest that you should leave a password blank? That's irresponsible.
For situations when you really want to have a service accessible from the console with no password, it is better to configure the system to skip the password request than to set the password to be empty. Basically a username/password combination can potentially be used to access any service on a Linux/UNIX system. Usernames are fairly easy to find for a system, so it is almost impossible to enforce any security policy on an account with no password. If you want a service or program to be accessible without a password it's almost certain that you want to limit the access to specific files (i.e. just your HTML files in your document root directory tree), through specific means (i.e. just through the web server, for read-only access), etc.
Anyway, many Linux systems are configured to forbid blank passwords. Thus, it may be that the installation program let you leave the password blank while the login program(s) are enforcing this common policy.

(?) How can i change it now? considering I am a newbie.....

Thank you Charles G.

(!) It depends. Is this a user account? Does logging in as 'root' work? If so, then just login as the root user (and open a "terminal" or "xterm" window if you've logged into a GUI) so you can type in commands.
First you need to know if the account you created exists.
Let's say you created your account name using your initials "cg." So you might use a command like:
grep cg: /etc/passwd
... if that doesn't pop-up a line that looks something like:
cg:x:0:0:Charles G:/home/cg:/bin/bash
... then you don't have a user account (or you mistyped something --- possibly when you created the account, or whatever).
You can create a user account using a command like:
useradd -m cg
... the -m tells 'useradd' to "make" a home directory for the new account. There are many options to the 'useradd' command. You can read more than you want to know about them by typing:
man useradd
Once you've created the account you can set the password using a command like:
passwd cg
... which, if done as 'root' will simply prompt you for a new password and ask you to repeat it. If you can type in the same string twice consecutively --- you will have successfully changed or set the password for that account.
You can also use the passwd command to change your own password by simply typing it (with no parameters or arguments). In that case it will require you to type your old password, and then repeat your new password twice.
Note that sometimes the 'passwd' command will complain that a password is "too short" or "too weak" or that it is "based on a dictionary word." The Linux 'passwd' command tries to enforce some "best practice" policies about your users password selections in order to make the system more secure. Basically anyone who cracks into a user account on a system has a pretty good chance of using that to take control of the whole system eventually. (Also they can do quite a bit of damage to that user's files and quite a bit of snooping about in that users e-mail etc. even if they don't manage to disrupt other users or the system itself).
I realize that you may not care about all this "security stuff" as a new Linux user. After all, you're probably adopting Linux after years of using MS Windows, which has no concept of users and makes no effort to protect the system from "normal users" or to protect any one users stuff from any other.
However, it's a good idea to take a lesson from Microsoft's mistakes. You may want to considering having one account on your system for reading mail, a different on for doing your web browsing, another for playing games, and yet another for any of your important work. (With a little practice it's possible for these to share data without too much inconvenience while limiting the damaged that a trojan horse (such as the ILOVEYOU e-mail virus) could do to your other work.
(Of course Linux systems are unaffected by ILOVEYOU, Melissa and all of the other e-mail trojan/viruses so far. However, such a problem might eventually affect some Linux users. Luckily there are many different e-mail packages in widespread use under Linux --- any bug that could be used to exploit one is very unlikely to affect more than a small fraction of the total population. This "technodiversity" (analogous to the "biodiversity" that we need in our ecosystems) does protect us somewhat --- since the infection can't spread quickly or easily unless there is a critically high percentage of "monoculture" applications users).
(I could write a long article on the pros and cons of technodiversity vs. standardization and code re-use. However, I have a feeling that it not be of much immediate interest to you).
Getting back to your problem. If you don't have a working root password then the job is a little more difficult. Basically you need to boot up the system in "rescue mode" or from a "rescue disc or diskette" mount the root filesystem, possibly mount a "/usr" filesystem on top of that, run the 'passwd' command, unmount the filesystems that you brought up, and restart the system from its hard drive.
Whoa! Did you get all of that? I didn't think so. Here's the same sequence again, with a little more explanation:
If you see the "LILO:" prompt while you're booting up the system you can usually hit the [Caps Lock] or the [Scroll Lock] key or just start typing to force the boot loader to pause at this point.
From there you can tap the [Tab] key to see a list of boot image "labels" (usually one will be named "Linux" or "linux").
From this prompt you can type a command like:
linux init=/bin/sh rw
... to bring up the system in a "rescue mode."
This will bypass the whole normal startup sequence and prevent the system's normal initialization program (init) from spawning the 'getty' processes that take over the console and force you to login.
BTW: It's possible to set another password on your LILO boot loader (adding a line to your /etc/lilo.conf) that would prevent this trick from working. That password, if set, would not convey any other access to the system, it would only allow one at the console during the boot up cycle to select and over-ride the boot settings.
The "rw" at the end is a convenience to make sure that the main (root) filesystem is brought up (mounted) in a read/write mode. Normally a UNIX/Linux system comes up with the root filesystem mounted read-only so that it can be checked and repaired.
You might have been offered a chance to make a custom rescue diskette during your installation. If you were wise you did.
If you system can boot from a CD drive then your distribution's CD usually can act as a "rescue disc." So you act as though you're going to re-isntall, but you use the keys [Alt]+[F2] (hold down the [Alt] key and hit the [F2], second function, key).
If that doesn't work, boot the system up under some other operating system or use a different computer and look for a "rescue diskette" image. Hopefully the instructions for that will be listed somewhere in your manual or on the web site for your favorite distribution. (Of course Corel's site is basically impossible to navigate if you're looking for technical support information specifically about their product. I doesn't seem to have a search engine and I don't see a link to a simple "Corel Linux FAQ").
Failing that look at Tom Oehser's site for his "Root/Boot" floppy (http://www.toms.net/rb) Unfortunately this is NOT a package for newbies.
If you booted from a rescue diskette you'd normally be running from a RAM disk. So you have to find your main (root) filesystem and mount it up. On a typical Linux system that would involve a command like:
mount /dev/hda1 /mnt
You need to know what type of hard drive you have (/dev/hd* for IDE, /dev/sd* for SCSI), which one it is (a for the first drive on the primary controller, and letters b, c, d, etc for others), and which partition it's one (1 through 4 for the primary partitions, and 5-12 or so for any logical drives in an extended partition).
Once you done that you should change into that directory (/mnt in my example and in most cases) and make that the "virtual" root directory using the following commands:
cd /mnt chroot . /bin/sh
Even if you booted from the hard drive using the init=/bin/sh trick, you may have to bring up another filesystem. The 'passwd' command is usually in the /usr/bin directory, and the /usr directory is often separated unto its own filesystem. (It's traditional though there are good reasons for this as well).
Here's the command to do that:
mount /usr
Finally you should be able to run the 'passwd' command to set a new password for yourself.
If you get some sort of error about a "read-only" filesystem then you probably forget the rw option at your LILO prompt. Use the following command:
mount -o remount,rw /
and try again.
If that was successful then you should be able to unmount any filesystem that you mounted:
umount /usr
... and if you were booted from a rescue diskette or CD:
exit; umount /mnt
... or if you were booted from the hard drive:
mount -o remount,ro /
This sets up all of the filesystems so that they are "clean" and can be used immediately after the next step without a time-consuming consistency check.
Finally you should be able to reboot. This is actually a bit trickier than you'd think when you've booted into this "rescue mode." (If you booted from a diskette or CD, just pull that out and hit the reset switch).
If you've booted from your hard drive using the init=/bin/sh trick (what I call "rescue mode" then you should shutdown and restart the system with the following command:
exec /sbin/init 6
... this is because the various sorts of 'shutdown' and 'reboot' commands usually are just sending a "signal" and performing some IPC (interprocess communications) with the 'init' program. In other words, normally only the init program does a reboot or a system halt (or changes "runlevels" --- operational modes). However, we bypassed the normal process and we're running a command shell instead of init. The shell isn't programmed to respond to signals by reading the /dev/initctl pipe (FIFO) for messages.
We can't just "run" init like a normal program. init detects what process ID it is running under and only assumes system control if it is process ID number 1 (PID ==1). If not then it acts as a messenger, trying to pass signals and commands to the "real" init process. However, our shell is running as PID 1 --- so we need to tell the shell to "chain over" or "replace its code with" that of init.
I realize that all of that was pretty complicated. You don't have to understand the inner workings of init in order to run this last command or to follow most of this procedure.
It won't even be the end of the world if you just hit the red switch and reboot the system. However, I've tried to make this set of instructions simple enough and general enough that it will work on most Linux systems.
If you get too stuck, call tech support. I see that Corel offers a fee-based North American telephone technical support option at about $50 per incident (I guess that would be in U.S. dollars). Of course my employer Linuxcare (http://www.Linuxcare.com) also offers per incident fee-based support as well. You could call them at 1-888-LIN-GURU for details.
There are also many Linux consultants that might be able to help you, possibly in person. Look at the Linux Consultants HOWTO (http://www.linuxports.com/howto/consultants/Consultants-HOWTO.html)


Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 54 June 2000
HTML transformation by of Tuxtops, Inc., http://www.tuxtops.com/


[ Answer Guy Current Index ] greetings   1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18 [ Index of Past Answers ]


[ Prev ] [ Table of Contents ] [ Front Page ] [ FAQ ] [ Next ]