completely locked out

I understand I will have to learn the equivilents to commands, arguments, etc. and disk file systems, etc. Booting dos for example is something like...

POST, then
system files load (io.sys, msdos.sys, command interpreter,stc), then
config.sys (devices drivers loaded and configured)
autoexec.bat (environment varibles, TSR's, programs, etc.)

I want to learn about the equivilent stages and or processes that apply.

Is this even where I should start? Or is there a broader base approach that would be recommended?

Please remove from the mailing list.

-----Original Message-----
From: aquilajohn <email address hidden>
Sent: Wednesday, February 13, 2008 6:01 PM
To: <email address hidden> <email address hidden>
Subject: Re: [Question #24596]: completely locked out

Question #24596 on kdebase in ubuntu changed:
https://answers.launchpad.net/ubuntu/+source/kdebase/+question/24596

aquilajohn gave more information on the question:
I understand I will have to learn the equivilents to commands,
arguments, etc. and disk file systems, etc. Booting dos for example is
something like...

POST, then
system files load (io.sys, msdos.sys, command interpreter,stc), then
config.sys (devices drivers loaded and configured)
autoexec.bat (environment varibles, TSR's, programs, etc.)

I want to learn about the equivilent stages and or processes that apply.

Is this even where I should start? Or is there a broader base approach
that would be recommended?

--
You received this question notification because you are an answer
contact for Ubuntu.

Hello,

Could you detail exactly what you did before you got completely locked out? Please be as specific as possible.

Thanks for your response, williamts99.

I cannot as it was just prior to leaving town for several weeks. I was in the gui, the section "system settings" and then I don't know for sure. I played around trying to remove the need to enter any passwaords at any time. I remember things like "users" "groups" and the one I probably got into trouble with was "convenience" as it warned me that I could render my computer unsecure (which is exactly what I wanted to do).

I'm sorry I can't be more specific, and unless there is some way to be able to save some configuation info without saving the problem I created, I will just have to start over. Maybe it will speed up my learning curve anyway.

I am not able to gain access to any area to make any further changes. Any time a password would normally be requested I get a test box like message. In the top header it reads "Kde su" and the message reads "su returned with an error" at the bottom it reads "please contact your administrator".

Thanks for your time and help. since I can't even tell you what it is I did, it may not be worth the time and effort to try to sort it out. Is there perhaps a log file somewhere that would go back that far and reveal what I did?

Thank you, aquilajohn (john)

Did you look at your /var/log/messages log?

You might want to check and see what groups you belong to on your computer. You might have to add yourself back to the admin group.

Best Regards,
Williamts99

Thank you both (williamts99 & Randy) for your time to respond. I will check the log file. As far as adding myself to the admin group, I can't. I can't do anything that would normally ask for a password. I can't even eject a cd from the drive as I am not able to mount or unmount any devices. When I say completely locked out, I really mean completely. To change a cd I have to reboot and catch the drive before kde loads, or boot to XP.

I don't want to waste your time, especially since I can't be specific enough to allow you to help me. So after checking the log file if nothing there is helpful I think I should start over regardless of what it takes. After all, I will learn much doing that and that it is the ultimate goal after all.

thanks, John

I found the /var/log/message file and another message.0 file that are since I got back to town after the month away. They are both dated in the last couple of days, way after the problem was created. Also message.1, .2, and .3 are there and dated back to december when I was likely to have done the damage, but they are not readable and I get a warning that if saved they will be corrupted because they are binary files. The extention is blank for the first file without an extention, lists "0" for the second. All three numbered "binary" files list "gz" as the ext.

I don't know if they contain any useful tidbits of information about what I did, but if they can be viewed I would be grateful for help on how to do that.

Also "completely" means all drives are also locked as "read only" as well.

OK, can you try to copy the message.x files to another system? the "gz" extension means that they have been compressed with the gzip program. You can use the gunzip program to decompress them and make them readable again (logs are just text files). If you can pinpoint the day that this happened then the lof giles will almost certainly have a record of what went wrong. if you can get them maybe you can mail them to one of us and we can help you look for what is wrong.

Hope this helps some.

Thank you very much Randy, and yes it is a BIG shot of help. Or at least hope. I will try to find a way to get a copy to unzip and work with. I will let you know either way.

Thanks again,

John

OK, good luck.

Hi Randy,

You sure have helped a huge amount just pointing me to the message files. I was able to unzip all three and they contain LOTS of info beginning around 12/21/07 and up thru 12/28. I can't decipher the lines entries much, but many boot / shutdowns are logged and they don't all look the same. At one point suddenly talk of "read only mandatory" seems to replace "read only default" (XML;readonly.....gconfig?.whatever). Would you be interested in checking them out for me? It seems with your help I at least have something for others who want to help to look at, finally. If so, what would you like me to do with them? I have your emails, can I just respond and attatch them to the response?

John

I piped you an email at <email address hidden> . . . send me your log files and I will take a look through them and see if I can come up with anything suspicious and if I do, I will show you what it is and maybe we can get this problem solved. If I can't find anything, at least we can maybe narrow it down so that some more eyeballs can scour it and find what the prob is.

Thanks, I really appreciate your time and willingness to help.

No problem. :)

I just got the log files. it may take some time to go over them all, but I will start looking. Also can you post the permissions of your sudoers file? Just do an:

ls -l /etc/sudoers

and tell me what you get . . . I want to see if the permissions of this file somehow got messed up.

Hate to be a pain but can you attach the /var/log/auth.x files as well? These contain security incidents such as password and permission changes. Any change in permissions of a file or access denied errors should show up in there.

Hi, the first one (sudoers file) returns "you do not have permission to view this file" The auth.x files are on the way. You are not being a pain...in fact each step has taught me something new just finding and unpacking and moving around the files. I have discovered I can unpack existing files to the disk if they already exist, but can't save or create new ones. I can't download directly to the disk, but the desktop is ok. (it's going to the disk by way of default set somewhere for downloads, but won't let me redirect from the default to send it to another directory)

When you try to do:

sudo ls -l /etc/sudoers

what is the exact error that you get?

Ayway, to tell you what I am doing . . . I am noticing a lot of rebooting going on around the 26-27 December in the message files so that gives me a time frame to look at to narrow down the problrem. Now I am going to check out the secure files that show things like password changes at around the same date and see what may have caused the lockout. Will let you know if I find anything.

I want you to try something. Do this and tell me what you get:

1. Reboot.
2. Press ESC at the grub prompt.
3. Press e for edit.
4. Highlight the line that begins kernel . . . then press e
5. Go to the very end of the line, add rw init=/bin/bash
6. Press enter, then press b to boot your system.
7. Your system will boot up to a passwordless root shell.

Try executing the command I gave you above and lets see if we can find out how you got stripped. But *be careful* . . . you can hose your system easily. We are just going to look around and see if the file permissions are correct.

To give you an idea of what I have been doing, you may want to look at the log entries from auth.log.2 that read:

Dec 21 22:17:01 Reno CRON[5372]: (pam_unix) session opened for user root by (uid=0)
Dec 21 22:17:01 Reno CRON[5372]: (pam_unix) session closed for user root
Dec 21 22:36:03 Reno sudo: john : TTY=pts/2 ; PWD=/home/john ; USER=root ; COMMAND=/usr/bin/kdesu_stub -
Dec 21 22:36:03 Reno sudo: john : TTY=pts/2 ; PWD=/home/john ; USER=root ; COMMAND=/usr/bin/kdesu_stub -
Dec 21 22:43:54 Reno sudo: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=pts/1 ruser= rhost= user=john
Dec 21 22:59:00 Reno sudo: john : TTY=pts/3 ; PWD=/home/john ; USER=root ; COMMAND=/usr/bin/kdesu_stub -
Dec 21 22:59:00 Reno sudo: john : TTY=pts/3 ; PWD=/home/john ; USER=root ; COMMAND=/usr/bin/kdesu_stub -
Dec 21 23:04:19 Reno sudo: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=pts/1 ruser= rhost= user=john

You will notice that the message "authentication failure" started popping up with some regularity, whereas before it was rare. Something around this time changed, so I made a note of the time of the frist denial message:

Dec 21 22:43:54 Reno sudo: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=pts/1 ruser= rhost= user=john

December 21, at 22: 43 or 10: 43 PM.

Now this is the "secure" or "auth" file . . . it shows things like authentications (and failures) and other security-oriented messages. So now I turn to messages.2 where I find the approximate time matching the first login failure above:

Dec 21 22:01:39 Reno dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.host_name
Dec 21 22:01:39 Reno dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.domain_name
Dec 21 22:01:39 Reno dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.nis_domain
Dec 21 22:01:39 Reno dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.nis_servers
Dec 21 22:21:31 Reno -- MARK --
Dec 21 22:41:31 Reno -- MARK --
Dec 21 23:01:31 Reno -- MARK --
Dec 21 23:05:07 Reno gconfd (john-5778): starting (version 2.18.0.1), pid 5778 user 'john'
Dec 21 23:05:07 Reno gconfd (john-5778): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0
Dec 21 23:05:07 Reno gconfd (john-5778): Resolved address "xml:readwrite:/home/john/.gconf" to a writable configuration source at position 1
Dec 21 23:05:07 Reno gconfd (john-5778): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
Dec 21 23:05:07 Reno gconfd (john-5778): Resolved address "xml:readonly:/var/lib/gconf/debian.defaults" to a read-only configuration source at position 3
Dec 21 23:05:07 Reno gconfd (john-5778): Resolved address "xml:readonly:/var/lib/gconf/defaults" to a read-only configuration source at position 4
Dec 21 23:21:32 Reno -- MARK --
Dec 21 23:41:32 Reno -- MARK --

So far I haven't looked at whether this part directly above is telling me anything useful, but I think we have a time and date pinpointed and it gives us some where to look. Will update you as soon as I find anything else.

Sorry for the delay since my last contact.......some days are better than others and neededI to take care of some work related problems. I will try the above and let you know how it goes asap. Hopefully within a few hours.
Also your focus on the times above is probably a good one because I do not remember finding out
I had problems until after I returned to town. That would mean that whatever I did would likely be very near the end of activity, just before the long period of inactivity. ( the end of december to about the middle of february)

Also in the last mess. file directly above it shows

Dec 21 23:05:07 Reno gconfd (john-5778): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0

Notice the "mandatory at the end of the quotes. I only remember seeing "default" in that same position in my scanning these files. Also all remaining "positions" noted except for one are also "read-only" with" default" not "mandatory". I have no idea what if anything that might tell us, but I believe it is different and or an inconsistancy from what I remember.

I'm off to experiment with the your boot suggestion, I will try to be precise and careful, but if the whole thing goes on holiday I'm still no worse off than before you helped me.

John

OK, here is what I have.

The first command (sudo ls -l/etc/sudoers) just returns another blank line beginning with the normal default cursor....

john@XXX:~$ sudo ls -l/etc/sudoers
john@XXX:~$

I read somewhere that in kde (and I thought it said) or even a terminal called from the kde gui, not to use "sudo" but rather "kdesu". I tried several different commands / syntax trying to get the security settigns for the files without success. I did get the following when calling "ls" with the -Z option. (the terminal called by menu from the kde gui) The blank spaces are just as they were returned. I know each "-" stands for something but don't know what (such as read, write, etc.)

john@XXX:~$ ls -Z /etc/sudoers
-r--r----- root root /etc/sudoers
john@XXX:~$

now on to the reboot with options as you asked for...
grub...edit..boot...shell.. then the original command you requested looked like this...

root(none):/# sudo ls -l /etc/sudoers
-r--r----- root root 403 Dec 13 14:27 /etc/sudoers
root(none):/#

I hope this helps. I have already learned so much just doing the few things you have asked I am grateful for your time and knowledge. I will someday be familiar enough to help someone else and will do so. I recall how difficult and time consuming learning dos was, but also how valuable command line usage became when troubleshooting. That is what is driving me to learn again so I can once again have control, know what the programs are doing, and be able to troubleshot and repair problems, such as this current one. Thanks again for your help, support, and mostly your time. John

OK, now that you are in as root (the # prompt indicates superuser privileges), you may want to try this: copy all of your userinfo to a temporary directory (could be /root/tmp or something like that. make sure you do a recursive copy and include the hidden files (configuration files). Then delete the user and remove the directory then recreate the user from scratch. Copy the files to his new directory and change the permissions so that all of them can be read.

kdesu is basically a graphical front end for su so unless you are running a graphical program or want to open a root terminal it is not much better than the regular sudo command . . . I normally only use sudo for single command lines so there isn't much of a difference for me.

My /etc/gconf/gconf.xml.mandatory file permissions look like this:

drwxr-xr-x 2 root root 4.0K 2007-04-15 06:54 gconf.xml.mandatory

So before trying the newuser trick you might try changing the permissions to tha above and seeing if they clear up your problem.

You did good with looking for inconsistencies in the logfiles . . . so I added the above line in case that's the problem, but I didn't see that much else either other than that.

Also the /var/log directory . . . notice how we have been relying heavily on that. You may want to familiarize yourself with this little area of your system . . . you can with syslog.conf increase the amount of information that is dumped to these logs . . . logrotate will prune them every month or so per your configuration, but you see how they can be useful in troubleshooting probs.

If this doesn't work let me know and we can try another approach to save your data.

And you're doing good, by the way . . . this level of poking in about the sysyem would scare the tar out of most beginners. ;)

By the way . . .

-r--r-----

this means the file is not a directory, that the root user and group have read access and no one else does. in general file permissions are liks this:

-rwxrwxrwx

The first dash indicates if it is a file, directory or block device. Usually you wil run into files or directories. A directory will look like this:

drwxrwxrwx

The r, w and x stand for read, write and execute. The first set is for the file owner, followed by the group and lastly for everyone else.

Thanks again for all your kind help and investment in time. I will try your suggestions and let you know what happens. I am just beginning to to visualize some structure that I can relate to the similar functions for other os's like dos. Is there a commonly agreed upon standard reference you could point me to, or maybe just one of your favorite ones that I can begin to study. What I am looking for is a broad overview that will then quickly focus down to the system structure or layout. Something that will list common type of files and system areas, or common collections and configurations that are basic building blocks to a system? You suggest I try to isolate the files containing user settings and the like, but I don't know which ones that is or where to find them in the directory structure. Heck, I'm still having to look up and search for devices and directories ( IDE0, IDE1, SCSI X, drive A, etc vs the device labels and assignments for this system.)

  Something like...

In the beginning there was unix.....
A smart student , Linus (sp), went overboard trying to impress his teacher = linux
   which is different in this way...
now everyone likes to play...
here is the foundation (kernel) that would be like dos system files
then popular options to add functionality includes examples like...
   capturing system devices, custom interface configurations, auto web updates, etc.
 dos does this by.....
here we do it with.....
now try to make it pretty, easy, and fun for all.....
time to show and tell with everyone else....
talk, dream challenge, dare, dream more, and then get back to work and see if you can do it better this time.
repeat cycle

minimum requirements to run, file types and how to identify, boot scripts and command line usage, the types of things that would relate to the other os as much as possible . Does such a text exist that you know of? If not you have an example of a lesson plan in your last post. What I learned in the few minutes it took to read your post took me about 90 minutes of hunting back and forth thru the documentation. I digress...
Once again thanks, I'll let you know what happens. And probably close out this thread as well.
John

OK, typically in a directory there are "hidden" files . . . these start with a dot (.) . . . now type:

ls -l

and look. Now type:

ls -la

Now you see all of your hidden files and directories. Now these usually contain configuration settings. Look inside the .mozilla dir for example. Your bookmarks, settings, cache and all that good stuff are there. So if you copy that usually you wil lretain your user based seetings. In Ubuntu the .local directory also has some important stuff. But these are typically user-based configuration/application settings. You may not want to cp them all, just the ones you actually need.

The main areas of the system to get used to in my opinion are the follwing areas:

/var/log
/etc
/etc/init.d
/proc
/boot

The other areas such as /usr . . . house maily application data wheras /tmp houses temporary data. /var/log contains all of your log files and that can be important. /etc is your system wide configuration files . . . /etc/init.d are the bootscripts that initialize (and kill) services as your PC biits up or is shut down. /proc is special since it houses a lot of your processes that are running. For example, try this:

cat /proc/cpuinfo

See the info that has? try some more of those files, as they tell you a LOT about your system.

/boot you don't mess with that much, but its where your boot material is kept. kernels and so on. You don't tend to use it much in practice but its good to have a looksee and familairize yourself with it. Get familair with how to use your man pages because it can tell you a lot. For example, I give you a command like

chmod a+x myfile.sh

and you don't know what this does.

man chmod

will tell you what the command does and its options . . . even something like "man ls" will show you a lot. Note: manpages are not known for their friendliness. It takes some getting used to to be able to get some usable info from them with any regularity.

Best best is to get a good book like "Ubuntu Unleashed" . . . "Unix Power Tools" is also good for command line expertise . . . and learn to hack your system by getting familar with it. A lot of it may SEEM overwhelming at first but really most of it is just getting used to how to do things and where to look.

You did good though. You asked the right questions, were polite and in general behaved just like someone who is eager to helps wants you to when advice is being given. (I wish everyone was like that).

One more comment about root . . . this may be unnecessary but I ought to mention it. Root is a powerful thing . . . *too* powerful often. ONLY use sudo commands when you NEED them, and NEVER log in as root or open a root terminal unless you have no other choice.

To give you an example, let me share a personal experience with you. I remember being told never to use root unless I needed it. I thought, well, I understand how it can be dangerous but only an idiot would type:

rm -rf *

right? Ahem. I opened up a root terminal and had another terminal open. As root I was in the boot partition. In my other terminal I was in a tmp subdir of my home directory. I was going to delte all of the files. So I typed rm -rf * . . . unfortunately it was in the wrong terminal. I did a Control-C to stop it, but . . . uh, well you can figure the rest out.

This was in fact at an HP-UX production database server at work.

Any questions? ;)

Also I read your post above about the POST process in DOS. try this:

sudo dmesg

You can also see the dmesg files in /var/log . . . these are your bootup messages. Most Linus systems show them to you on boot, but because Ubuntu uses KDM/GDM login managers bny default they seem hidden. But you can normally see the messages scroll by. (I use fluxobox and don't use a login manager because I like seeing this, but its up to you).

Great! Randy, you have given me enough leads to follow to keep me busy for a very long time. This is exactly the direction I was hoping to be pointed in. I agree the man pages are a challenge. Sorry to hear about server at work...quite a massive repair compared to my current problem.

I have not yet fixed my problem, but I have enough access to feel I should spend some time on my own trying find and solve it. I will tinker with each of your suggestions / lessons and read the suggested books. Thanks for the book suggestions. I know there are hundreds available, but wanted to start with something that would be most beneficial to me and my situation and style. After these few days working with me, your suggestions are sure to be just what starting point I need.

After playing with your hints and tips above I thought I would pick up a 40gig HD at the used computer store and install the whole thing again over on it. Then I can go back and forth between them as I set up everything again without losing what I have. I have a reference as well as a source of the files to try swapping one at a time and observe the changes.

You are right, I am excited and having fun. Overwhelmed I'm not, but fully aware this is a never ending process that will take as much time and effort as I give it. The learning curve is the toughest at first.

Several times during the past year I began this project (moving to the open source community and leaving the monopoly behind) and set it aside not even able to load and launch ubuntu / kubuntu. After three or more false starts I finally got to where I was up and running, only to get a big head and lock myself out. Again, I been very close to setting it aside, but not about to now because of your assistance. I may not be able to completely abandon the behemoth just yet, or ever, but I committed to learning this alternative and will.

Thank you so much for your kind assistance. Everything I read about the open source community and it's future depending on people participating could not be better represented in spirit and action than you have and are doing.

Thanks again,

John

I'm closing this question

I am glad I could help. Try figuring out your problem before reinstalling . . . once your data is safe, there is nto much harm in going in as root and poking about trying to recreate the problem if you are going to reinstall anyway, but troubleshooting like this can be a valuable learning experience (as can screwing up your system). I am sure you wil do fine. Good luck.

Thank you. To clarify, I'm planning to install a separate new copy on the additional hard drive so I will have both. My bios allows boot interuption in order to point to the desired device, so I can go back and forth from this nonworking present set up to the fresh start copy. (I suppose grub would work too) I'll be able to compare files side by side, and when needed move / rename / replace files on the broken system with nonbroken system copies.

You hit a grand slam home run with "unix unleashed". It is exactly what I was looking for. Couldn't hope for a better match to what I wanted.

I am having a absolute ball already. Chmod kicked my fanny for about two hours, until I started over using OCTAL MODE instead of letters. Despite showing permissions changes for sudoers to -rwxr--r-- or -rwxrw-r-- in the bash shell, kde (and any terminal called through the gui) still shows the old -r--r-----. It's only a matter of time before I find out where and how kde is loading the old information and tricking it into updating (or swapping a file to do it ) the configuration as it loads. I'm getting tons of practice as I always change the permissions back before shutting down. (I'm such a worry wart I turn off my dsl hardware while I play with sudoers and there isn't even any personal or financial stuff on this machine).

Thanks again for everything and I'll try to remember to shoot off an email to you if and when I find and correct the true root cause of my mistake.

John

If you are interested in seeing your system booting up, you may want to switch to a virtual terminal with Ctrl-Alt-F1 . . . if you have never seen this before, it might be interesting. Ubuntu hides it by default since some people find it intimidating.

I think you will solve the problem pretty soon, just keep going through your system until you isolate the only other thing you could have done, and making a note to avoid it in the future. having a side by side comparison system is a good way to find what's different.

But you're doing really good. Good luck!