I was running a tty as a user. I wanted to change my password so I entered

passwd

I put the old password, and the kernel replies that the password is incorrect. I'm positive that I entered my password correctly, I even made sure by using john the ripper. Also, I've noticed that when I run some setup menus in gui(like hplip or autologin menus), it asks for root priveleges, so I enter the correct password, and the gui replies that I have entered the incorrect password, even though I'm sure that I entered it correctly (verified by su'ing to root). What gives?

I had problems ssh-ing from one machine to another, and it turned out to be an incorrect keyboard layout mishandling special symbols. I would check each character in your password to ensure that none of them are being sent improperly.

The kernel does nothing with your passwords as far as I know.

Have you mounted /etc on a separate filesystem? This could cause the wrong password file being checked. The passwd file resides in /etc and if you made this a filesystem the following would occur:

- system boots up
- checks being run pre-mount
-- if the password is being asked prior to mounting the drives, the password from the passwd file on the root filesystem is being checked
- filesystems get mounted (but the mount can fail)
-- if /etc is mounted on another filesystem, passwords and updates on the passwd file are being checked against the file in the mounted filesystem

Be advised that /, /etc, /proc, /lib and /sbin should not be mounted separately, with the exception for /proc if it is of type procfs, which the kernel can handle.
/lib contains kernel modules and as such must be available before mounting, /sbin contains files that are necessary for system recovery, so they must be available before mounting as well.

Since you could log in (to type "passwd") it seems something else may be happening. What do you get when you type "passwd -S" ?

Not necessarily... Systems can be configured to auto-login to a specified user via GDM and KDM (not sure about XDM).

boo! :-)

I conveniently "forgot" that option for KDM, afaik only KDM offers this option, XDM could maybe be configured that way if you hacked deep enough working with SSH certificates (just a wild guess)

Still, typing "passwd -S" will probably give a good indication on what's up with the password. Since trist007 could type "passwd", a "passwd -S" should indicate what the status of the password is. It could say NP (No Password), indicating the field is blank, or that there is (no) shadow password, the account may be indicated as locked (but why and how could that be if the user can log on?) etc... It's a first step in several to see which direction the solution should be found.

Well trist007 did say s/he could su to root, so sometimes the password is recognized correctly but sometimes not. I'm still banking on a keyboard mapping/locale issue.

GDM can certainly be configured to automatically log in, here are some instructions:
http://www.perturb.org/display/entry/812/

I think the problem is that I am unable to use the su command. I can use it, but the password I put in for root doesn't register, even though it's the correct one. However, I can sudo -i into root.

I have made an entry in the /etc/sudoers file that says

%users ALL = ALL

Should I change that line to


trist007 ALL = ALL


Because I'm always using commands that require root privelegs. I'm the sole user of the OS, so it's just root and trist007 as users. I use the OS for everyday stuff as well as pentesting, training to be a professional pentester. When I'm pentesting, it's a pain because I have to prepend every command with sudo, but I heard it's a safer practice not to log on as root. However, when I'm pentesting, I'm pretty much sudo'ing everything, so even if one of those processes were compromised, the attacker would get root privs anyways. However, I know that not being root can avoid stupid mistakes like
rm -rf / /tmp or so. So in that sense it's good.

I think I can not use the su command because trist007 is not part of the wheel group. Is this the reason? Of course, as trist007, when I sudo, I just use trist007's password to get root privs. I can log in fine. Also, when I run firefox as trist007, I do not have access to the sound device, no sound plays on somafm.com or youtube. So I have to sudo firefox to get sound. What's the /dev/ I'd have to change permissions to get trist007 to be able to access it. Which permissions would trist007 need on that sound device? Just execute permission?

Also, I've been rebuilding the kernel and experimenting with different options. I've felt a huge boost enabling pre-emptive low latency kernel, high memory support, 1000 Hz, etc. Also, I have a Q6700, so I selected Core 2 as processor. Once bzImage was finished building, the bzImage was in i386 and not x86_64. I know i386 is a standard, but wouldn't my processor get more out of using the x86_64 arch? There was no bzImage in the /usr/src/linux/arch/x86_64/boot dir. In any case, my os runs significantly faster.

Will I notice a big difference if I enable dynamic ticking or should I stick with the 1000 Hz ticker?

Also on my toshiba satellite m305d-s4830, I goofed. I've been rebuilding the kernel using xconfig, so that I could get readings on how much charge I have left on the battery. So I enabled most of the stuff in the ACPI package, even deprecated stuff. I can get readings now both in /proc/acpi and /sys/class/power_supply. However, now when my ac battery pack is plugged into the wall and the laptop and I enter the poweroff command, my laptop reboots instead. Now if I disconnect the ac adapter, then the poweroff commands executes correctly. I wish I knew which options I enabled that caused this glitch, cause I don't want to POE each option in the ACPI package to find out which one caused this symptom. Any of you guys know of an option or combination of options in the ACPI package that would causes such a symptom?

I think a lot of your recent questions would get better exposure with separate threads, but I'll answer where I can.
I guess I misunderstood your original post. Under which circumstances is the root password accepted, and when isn't it?
Absolutely - basically you're allowing any user in the users group to run any command by prepending "sudo" and entering their password (unless you have targetpw in Defaults, which you don't seem to have since you use your user password). You might want to use "%adm ALL = ALL" and then add trist007 to the adm group, so if you add a user in the future you can just decide whether or not to add them to adm instead of editing sudoers.
I doubt it - the permissions are likely -rws--x--x so anyone can run it, unless you've installed some selinux extensions.
No, you need to be able to write to the device. Assuming the audio device nodes are owned by the audio group, you just have to add trist007 to the audio group.
I don't know about big difference, but if you decide to use a VM in the future you might have issues with a tickless kernel. You can always rebuild it if that's the case though, so it's certainly worth experimenting.

I can't use 'su' only sudo. I can use 'su' but the password won't get accepted even though it's correct.

Can you sudo su?

See my next quote part: I think you're mixing sudo and su up. In very short what I'll tell later: su needs the password of the target user (in your case "root") sudo requires your own password.

Depending whether this system is directly connected to the internet, I would say that running your daemons and services under root privileges is an unwise thing if they are (to be come) compromised. There's a reason that httpd, sendmail etc run under special user accounts by default. But it's your system and you can tinker around I suppose ;-)

No, this is not the reason. Su does NOT use the sudoers file, instead su means "switch user" or something akin and will ask for the password of the "target" user. The workings of sudoers is different and privileges are set by the sudoers file. If the user issuing a command via sudo is allowed to run that command as defined in the sudoers file and has authenticated being that user by giving his own password then sudo will run that command with root privileges by using the setuid bit.

Getting an x86_64 kernel requires a bit more than selecting your processor. It also requires other things to be set to make everything 64bit.

That may depend per system, my guess would be to check out the help in the kernel configuration utility (make xconfig, make menuconfig etc) you use.

I think this part is best to be covered in another thread. I noticed a symptom like that on the forums and it could even be your post ;-) no need to double stuff up anyway.

I hope my post enlightened things a bit

You're welcome ;-) Does this mean the password problem is solved now?

Yeah sure does, I got sudo and su confused.