More Funny Applications Errors From Linux, Unix And Elsewhere

Hey There,

Well, the sunny breezy weather forecast out here in Chicago has turned out to be nothing but oppressive humidity (which almost never happens ;) so I've spent most of my day seeing spots. Thankfully, around these parts, the fall, winter and spring take up a lot more of the year than the summer (or maybe it's just that the winter gets so freezing cold that it seems longer. Whatever it is; I love it and it makes this misery bearable ;)

I ran into another "bad slab magic error" today, installing an older version of RedHat Linux on a freebie junk-pc that a neighbor decided to punt to the curb and it was hard not to crack a smile (I don't know why that error always makes me laugh. It just sounds really really goofy to me, and I love goofy humor :)

Anyway, that error message got me thinking that I haven't scoured the net for funny error messages in a while, but, thankfully, folks are still posting them like they're going out of style (I think, in fact, that the opposite is true and they have yet to come into their own ;)

This batch of funny application error messages below was found on the Waikato Linux Users Group Site, and they deserve all the credit for either collecting these gems or (I'm not here to judge) making them up. If it sounds reasonably credible (which most incomprehensible error messages do, nowadays), I'll put aside whatever I'm doing to chuckle for a moment or to. Even if I'm only chuckling on the inside ;)

They (Reader's Digest ;) say that laughter is the best medicine. If that's true, this page will do you some good. If you've gone and severed a limb, you may need to go see a doctor. That's one of the ailments they almost never misdiagnose and, although they can cure it, there's rarely any laughter involved.

It's a backward, upside-down, topsy-turvy world ;)

Cheers,

---

Messages reported by applications and OperatingSystems

These are some of the funny, sarcastic, or just plain stupid error messages that you might see. If you are looking for "proper" error messages from applications, and how to resolve them, look at ApplicationErrorMessages.

Keyboard not found. Hit F1 to continue

Many BIOSes will report this error if a keyboard is not found at boot time.

lp on fire

The Linux lp# driver says this when your printer signals an error, but doesn't signal which error. Usually this means the printer is offline. (This message was copied from much earlier line printer daemons from Unixes of old.)

Update: Kernel 2.4.20 contains the following change from 2.4.19:

 diff -urN linux-2.4.19/drivers/usb/printer.c
 linux-2.4.20/drivers/usb/printer.c
 --- linux-2.4.19/drivers/usb/printer.c  Fri Aug  2 17:39:45 2002
 +++ linux-2.4.20/drivers/usb/printer.c  Thu Nov 28 15:53:14 2002
 @@ -257,7 +257,7 @@
   * Get and print printer errors.
   */

 -static char *usblp_messages[] = { "ok", "out of paper", "off-line", "on fire" };
 +static char *usblp_messages[] = { "ok", "out of paper", "off-line", "unknown error" };

Q276304 - Error Message: Your Password Must Be at Least 18770 Characters and Cannot Repeat Any of Your Previous 30689 Passwords

A Microsoft Windows error message as reported by comp.risks 21.37

You don't exist. Go away.

This message appears for certain unix programs when an entry can't be found for you in /etc/passwd (or these days, via PAM). This might be because you've not logged in via login(1) (this can happen if /etc/inittab specifies a program that doesn't log you in, instead of getty(8)), if your machine can't retrieve the data from the network (if you are using NIS or LDAP or some other network user administration system) or if you've made a mistake editing /etc/passwd (or friends).

Curse on you, wizard, before you recurse on me.

bibtex(1) style files use an undocumented language called BST (or that's the file extenstion, which is the closest it has to a name). In this language recursion is prohibited, and this is the message you get if you try it.

I refuse to debug myself!

If you tell GDB to try to attach to its own process. (It can't run it and breakpoint it and the same time.)

The devil is in the details: zero number of heads or sectors

Seen from the mdir(1) command.

MicrosoftWindows MSI Installer

Software Installation encountered an unexpected error while reading from the MSI file \\mlc1\deploy\FireFox-1.0.1-enUS.msi.

The error was not serious enough to justify halting the operation.

The following error was encountered: The operation completed successfully.

sudo(1)

If the insults flag is set in /etc/sudoers, sudo(1) will return one of the following errors when an invalid password is entered:

• Just what do you think you're doing Dave?


• It can only be attributed to human error.


• That's something I cannot allow to happen.


• My mind is going. I can feel it.


• Sorry about this, I know it's a bit silly.


• Take a stress pill and think things over.


• This mission is too important for me to allow you to jeopardize it.


• I feel much better now.


• Wrong! You cheating scum!


• No soap, honkie-lips.


• Where did you learn to type?


• Are you on drugs?


• My pet ferret can type better than you!


• You type like i drive.


• Do you think like you type?


• Your mind just hasn't been the same since the electro-shock, has it?


• Maybe if you used more than just two fingers...


• BOB says: You seem to have forgotten your passwd, enter another!


• stty: unknown mode: doofus


• I can't hear you -- I'm using the scrambler.


• The more you drive -- the dumber you get.


• Listen, burrito brains, I don't have time to listen to this trash.


• I've seen penguins that can type better than that.


• Have you considered trying to match wits with a rutabaga?


• You speak an infinite deal of nothing


• You silly, twisted boy you.


• He has fallen in the water!


• We'll all be murdered in our beds!


• You can't come in. Our tiger has got flu


• I don't wish to know that.


• What, what, what, what, what, what, what, what, what, what?


• You can't get the wood, you know.


• You'll starve!


• ... and it used to be so popular...


• Pauses for audience applause, not a sausage


• Hold it up to the light --- not a brain in sight!


• Have a gorilla...


• There must be cure for it!


• There's a lot of it about, you know.


• You do that again and see what happens...


• Ying Tong Iddle I Po


• Harm can come to a young lad like that!


• And with that remarks folks, the case of the Crown vs yourself was proven.


• Speak English you fool --- there are no subtitles in this scene.


• You gotta go owwwww!


• I have been called worse.


• It's only your word against mine.


• I think ... err ... I think ... I think I'll go home

(Taken from ins_*.h in the source for sudo 1.6.6)

---

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

UnConfusing The Issue Of Disabling Root On Linux or Unix

Hey There,

Loosely following up on a few previous posts regarding securing Linux and Unix and even more fun with Unix and Linux security, today we're going to look at something vaguely security-related, and also vaguely scary ;)

It has to do with the root account (or user id 0) and security hardening. I've got nothing against either, so this won't be an insane diatribe, but (especially, no offense to Ubuntu) with more Linux distro's coming straight out-of-the-box with root disabled, I see the issue of security and the root user get a little confused. A lot ;)

There are a numbers of things at issue here, and they're all loosely tied-together by the common thread of an earnest striving for better total-system security. Today, I'm just feeling like clearing some of them up to the best of my ability, before they make me nuts.

1. Having a disabled root account and removing a root account are two entirely separate things. As I mentioned above, Ubuntu comes with the root account disabled (basically, you can do this on any OS by running "passwd -l root" as the root user, hopefully setting a regular user up with a sudo rule so they can su to root if they need to later, and then exiting out of the root account).

This is perfectly fine. It upsets quite a few people who don't know what to make of it, initially, but it's not a bad idea. The root user's password is locked, so no one can su to it without sudo (or some other privilege-escalation vehicle), but the account still exists and runs as normal.

It goes without saying, at this point in the post, that actually removing root (userdel root will fail - probably too late - but you can accomplish almost the same thing by editing /etc/passwd, /etc/group, /etc/security/*, etc, as root and logging out) is a bad idea. The problem then becomes that, not only can no one su to root, it's actually gone, and everything that used to run as uid 0 will begin to exhibit bizarre behaviour. Without intervention you can expect to lose your system fairly quickly and have the boot process crash on you as soon as it gets to running init, at best. By default, on almost every system I know, init runs as root, spawning "init" (process 1 - the mother of them all). If that can't start, what else can? I've heard tell of systems that will revert to the nobody account to run this, but I've never seen it happen and I can't imagine how it would work...

2. There are ways to run your system without having a root user, but almost all of them are not worth the effort. As a blanket statement, if you replace the root account with another account with uid 0 (Except in such instances as FreeBSD, where they've gone through the trouble of actually coding out a "toor" user as a root variant), you're opening up the door to any number of problems you may have not foreseen. Replacing uid 0 with uid 100034 (pick a number) would be even more probable to cause stress-related fatalities ;) Liken it to the old-style firewall security method of "block what you don't want and let everything else in." That philosophy was eventually replaced by the more sensible "block everything and only let in what you want" method. If you mess with root, or uid 0, you may have a huge list of things you've accounted for, but you're almost guaranteed to stung by something you'd (and anybody else probably would have) forgotten or never even considered.

3. Changing init in Linux using the boot loader (with arguments like init=/bin/bash) doesn't actually address the issue with running init without root, or a user with uid 0. This trick can come in very handy when, for instance, you want to subvert LILO or Grub security and boot into bash. Of course, / will be mounted read-only, but it's only a minor inconvenience to run "mount -o rw,remount" on it to begin editing files you shouldn't be editing. Of course, you'd only end up doing this if you were in it deep and had to manually edit your /etc/shadow file or something, right? Yes. That's the ethical answer :) As far as hardening security goes, I'm not sure how this misconception got started.

4. Having more than one user with uid 0, or more than one group with gid 0, is not only insane, it's lazy-insane ;) Seriously, I've seen this proposed as an alternative to locking root's password and using sudo in order for certain users to access root to make changes as the superuser. There are a few issues with this sort of convenience, none of which are good (except, that 5 or 6 guys on your system have uid 0 and root privilege which is great! ...I mean bad). Aside from the simple "plus 1" factor of risk-of-accidental-keystroke-downing-your-machine incidents per user with said privilege, having multiple users with the same uid and/or gid can cause erratic behaviour with programs that do name-to-uid and/or uid-to-name mapping (like the login command).

All of this comes back to locking up the root user password. This is (assuming you have to pick from that and the 4 options above) the most sane choice. I'm not gonna shine you on about how I've never used root as my main account for years on end and haven't ever accidentally deleted the /dev filesystem (well, at least as much as it would let me before there was no device left to do the deleting ;) I've done lots of crazy and irresponsible things in my career and, according to some folks (like the U.S. military and heavy-hitting banking and/or securities-trading companies) I still do, no matter how good I try to be ;)

But I think, if you must tighten the screws on the root account, then look to Ubuntu's example and have the default setup with a locked root password and a user account that can "sudo su" to it. There's no need to be any more extreme or creative and, if you decide that you must and haven't completely profiled your operating system's kernel and shell code before implementation to ensure safety from latent dependency bugs (or somehow managed to figure out a way to defend against an army of guys/gals with root privilege easily and with guaranteed low-downtime), may luck be with you. And, if it's not, may you have an understanding superior.

Hopefully, this hasn't confused the issue even further. Whatever the issue was... ;)

Cheers,

, Mike

Prtdiag And "Lane Width Failed" Errors On Solaris 10

A lot of admins who work with Solaris 10 Zones may have run into this situation already, but I'm just starting to hear it now from users who like to do their own diagnostics before coming to me with a possible system issue. Don't get me wrong folks; I love it when users show this kind of initiative (as long as they don't go into the data center and start pressing buttons ;)

This problem is similar to the problem Solaris 10 has with old style /usr/ucb/ps, but it isn't quite as prevalent.

The situation that occurs is that a user, trying to gather information on the system that may, or may not be, having a hardware or software issue, runs a pretty standard command called "prtdiag," probably like this:

host # /usr/platform/`uname -i`/sbin/prtdiag

Now, in Solaris 10, this doesn't always cause an error. The reason for this, and how it differs from the old style ps error, is that it only occurs when the user runs prtdiag on Solaris 10 with Zones enabled.

Another thing that makes this unusual error so rare is that, on most Zone-enabled Solaris 10 setups, users accounts are all setup in the non-global Zone and prtdiag will only run in the global Zone. Obviously, the "rules" aren't followed all the time, insofar as system setup and access are concerned. Like they say: the customer is always right, even if he's doing something he probably shouldn't be (or something like that ;)

So far, I've only seen this error on the Mx000 Series Servers from Sun, but that's probably because we use those the most. Generally, the error will present itself in some way similar to the following (Looks scarier than it is and the actual error may vary)

host # /usr/platform/`uname -i`/sbin/prtdiag <-- Stripping the 100 lines preceding the error in my ongoing effort to fight eye-strain ;)

... 
    IO                                                Lane/Frq 
LSB Type  LPID   RvID,DvID,VnID       BDF       State Act,  Max   Name                     Model               
--- ----- ----   ------------------   --------- ----- ----------- ------------------------ ------------------ 
    Logical Path 
    ------------ 
Getting lane width failed for path /pci@3,800000/SUNW,emlxs@0

And, again, just like our ps error on Solaris 10, running the command as root makes everything work just fine:

root@host # /usr/platform/`uname -i`/sbin/prtdiag

...
    IO                                                Lane/Frq 
LSB Type  LPID   RvID,DvID,VnID       BDF       State Act,  Max   Name                     Model               
--- ----- ----   ------------------   --------- ----- ----------- ------------------------ ------------------ 
    Logical Path 
    ------------ 
00  PCIe  3      1, fc21, 10af        1, 0,  0   okay     4,  4   SUNW,emlxs-pci10af,fc21   LPe110094-S           
    /pci@3,800000/SUNW,emlxs@0

Sun's stock answer, for now, is to change the permissions of the prtdiag command so that it runs setuid root (For those of us who are reading this and don't know what that means - A very small portion of the audience that bothered to read this far, I'm sure - when a program is setuid "username," it will run as that user - with that user's privileges - no matter what user actually executes it)

root@host # chmod 4755 /usr/platform/`uname -i`/sbin/prtdiag

or, if you prefer to change your file modes in alpha:

root@host # chmod u+s /usr/platform/`uname -i`/sbin/prtdiag

Probably the best way to work-around this, and keep with Sun's basic security requirement of not running programs like this setuid root, is to make use of a program called sudo (which comes with Solaris 10). Just include a rule like the one below, so that users can only run "/usr/platform/`uname -i`/sbin/prtdiag" straight up and can't run it with any additional flags or switches. This will allow them to get the information they want and safeguard you, the admin, against any unforeseen issues with this work-around. Example rule below:

ALL ALL = (root) /usr/platform/`uname -i`/sbin/prtdiag ""

Another promise from me that, eventually, we will get to a post devoted entirely to sudo. For now, here's a quick rundown on how this rule reads:

ALL <--- All users can use this sudo rule
ALL <--- This command can be used on any host.
= <--- The cement that connects the preceding user and host restrictions with the commands and options to follow
(root) <--- This command will be run as the user root
/usr/platform/`uname -i`/sbin/prtdiag "" <--- This is the only allowed command. This command specifies that /usr/platform/`uname -i`/sbin/prtdiag can only be run with no additional switches or flags (like "-v"). The "" (double-double quotes) indicate that no switches are allowed after the command.

Hopefully, and in all likelihood, this solution should keep everyone happy. You've kept the security flaw from being exploited, retained the original permissions on /usr/platform/`uname -i`/sbin/prtdiag and allowed users to be able to get their diagnostic output.

All that's left to do is thank your user base for helping make your job easier :)

, Mike

linux unix internet technology

Old Style ps On Solaris 10

A lot of admin's may have heard this complaint already, but I'm just starting to hear it now from users who are upset about the change in functionality of the /usr/ucb/ps command (as opposed to the standard /bin/ps command).

Up to Solaris version 9, "/usr/ucb/ps -aguxwwwww" would give you extremely detailed ps output (like the entire 2 pages of output from a java command, for instance). Theoretically, in Solaris 10, it still does. Alas, in reality, it doesn't. Here's a link to the publicly available Sun Alert Notification that explains the issue in more detail.

The reason for this stems back to a vulnerability (feature ?) that was discovered in Solaris 8 and 9, regarding /usr/ucb/ps, whereby a user could use the program to view another user's environment settings/variables if they used the "-e" switch. Patches were released for both Solaris 8 and 9, and Solaris 10 was claimed to not be affected by it.

However, all the security patches for Solaris 8 and 9 really did was strip the setUID bit on /usr/ucb/ps and Solaris 10 was released with a /usr/ucb/ps binary that came with 0555 permissions standard (users could no longer get the extended output, but root still could). This would suggest that, perhaps, Solaris 10 wasn't ever really "immune" to the vulnerability, but, more simply, came with the work-around set as the standard. A quick test shows that this is, indeed, the case. Check out the following on a simple /usr/ucb/ps test against the cron process. Note that this is run on a Solaris 10 box, with very recent patch-levels, and I've changed the permissions of /usr/ucb/ps from 0555 to 4555:

host.xyz.com # uname -r
5.10
host.xyz.com # /bin/ps -ef|grep "[2]35"
root 235 1 0 Sep 12 ? 0:07 /usr/sbin/cron
host.xyz.com # /usr/ucb/ps -eaguxwwww|grep "[2]35"
root 235 0.0 0.0 2840 1864 ? S Sep 12 0:06 /usr/sbin/cron LC_COLLATE=en_US.ISO8859-1 LC_CTYPE=en_US.ISO8859-1 LC_MESSAGES=C LC_MONETARY=en_US.ISO8859-1 LC_NUMERIC=en_US.ISO8859-1 LC_TIME=en_US.ISO8859-1 PATH=/usr/sbin:/usr/bin SMF_FMRI=svc:/system/cron:default SMF_METHOD=/lib/svc/method/svc-cron SMF_RESTARTER=svc:/system/svc/restarter:default TZ=US/Central

Looks like the problem hasn't actually been "solved."

So, there you have it; /usr/ucb/ps on Solaris 10 actually does still show regular users the environments of any user that calls a program. Of course, stripping the setUID bit makes that impossible again, but it also makes it impossible for regular users to get extended output for those long java command lines that they need to see.

There are several work-arounds for this work-around. For instance, you could try to use "pargs." It won't work without the setUID bit either, but at least it will tell you that it can't and not just shoot you truncated output with no explanation.

host.xyz.com > pargs -e 235
pargs: cannot examine 235: permission denied

Probably the best way to work-around this, and satisfy Sun's security requirements is to make use of a program called sudo (comes with Solaris 10). Just include a rule like the one below, so that users can only run "/usr/ucb/ps -aguxwwww" and can't run /usr/ucb/ps with any other command arguments, except straight-up with no arguments. They'll get the long output they need and will be prohibited from running /usr/ucb/ps with any other command line switches, like the terrible "-e." Example rule below:

ALL ALL = (root) /usr/ucb/ps -aguxwwww, /usr/ucb/ps ""

We'll go into more detail about sudo in a future post, in all probability. For now, here's a quick rundown on how this rule plays out:

ALL <--- All users can use this sudo rule
ALL <--- This command can be used on any host.
= <--- Pretty self explanatory ;)
(root) <--- These command will be run as the user root
/usr/ucb/pas -aguxwwww, /usr/ucb/ps "" <--- This is the list of allowed commands. The first command specifies that /usr/ucb/ps can only be run with the "-aguxwwww" switches. The second command (multiple commands separated by commas) specifies that the user can also run /usr/ucb/ps with no switches at all (The "" (double-double quotes) indicate that no switches are allowed after the command)

Now, everyone should be happy. You've kept the security flaw from being exploited, retained the /usr/ucb/ps permissions, satisfied the Sun Alert requirements and allowed users to be able to get their extended ouput.

If only every annoying problem were so easy solved ;)

, Mike

linux unix internet technology