Subtle (and sometimes maddening) Unix/linux diffs

[W1GUH]

As I venture into the great world of linux, I keep finding subtle differences that are frustrating and maddining. The two that I so far have learned are...

linux (unlike Unix) has no "current dir" default. In Unix, if there's an executable in the current directory (pwd), simply typing the name of that executable invokes it. Not so in linux (at least Ubuntu). There, you have to explicitly tell it to look in the current dir, e.g. ./<exeutable>.

The other one is outlined in the cryptic "grep" post, where the "tic" (the character under the tilde (~) in the upper left hand corner of the keyboard has a different meaning in linux than unix. WTF? I just have to wonder about these differences, like, WHY? It makes the transition from unix to linux, IMHO, unnecessarily difficult. Is there an easy to grasp explanation of these differences?

(Don't get me wrong...I love linux, and I'll put up with this...but this stumps me)

[W2NAP]

i remember asking the same kinda questions few years ago...

i dont think i ever got my answer

[W1GUH]

Thanks. It's good to know I'm not alone!

[n0iu]

As I venture into the great world of linux, I keep finding subtle differences that are frustrating and maddining. The two that I so far have learned are...

Well, if Linux was exactly like UNIX, then it would be... UNIX!

Way back in a previous lifetime, I used to do UNIX support and administration. I still have a single user copy of SCO Open Server 5.0.4 that I used to get certified laying around here somewhere and I have been meaning to install that on one of the spare PC's around here... one day... when I get the time.

A little OT, but what sold me was the fact that one of our customers was running a primary and backup PC for their business and the hard drive on the primary PC was starting to fail. When I put the backup online and started digging around in the original primary unit, I discovered from the log file that this computer had not been rebooted in over 5 years! After running 24/7/365 for that long it was entitled to fail!

Where I work now, the head of IT has us reboot the Windows PC's at least once a week! Its all about marketing, not about quality.

[ka8ncr]

As I venture into the great world of linux, I keep finding subtle differences that are frustrating and maddining. The two that I so far have learned are...

linux (unlike Unix) has no "current dir" default. In Unix, if there's an executable in the current directory (pwd), simply typing the name of that executable invokes it. Not so in linux (at least Ubuntu). There, you have to explicitly tell it to look in the current dir, e.g. ./<exeutable>.

That is a shortcoming of the shell. I think the reason has to do with a separate hash table that's built from the PATH statement. In order to have it try the current directory, it would have to build or add where you're working. And hash tables are expensive to rebuild, and who wants to rehash each time you change a directory in order to keep the table size manageable? But that's just my guess.

It's an interesting issue though, I think I need to ask around why it is so.

Also, it's not just Linux. I've seen this behavior on SGI Irix and a very modern Sun system as well as my Mac.

The other one is outlined in the cryptic "grep" post, where the "tic" (the character under the tilde (~) in the upper left hand corner of the keyboard has a different meaning in linux than unix. WTF? I just have to wonder about these differences, like, WHY? It makes the transition from unix to linux, IMHO, unnecessarily difficult. Is there an easy to grasp explanation of these differences?

sed and awk have some peculiarities too...

[KC2UGV]

Not having "./" in your path is a purposeful design decision (Which you can change by adding "./" to you end of your PATH).

Let's say, as a mutli-user system, you are in a public directory. Well, you just got an email that you need to change your password. So, you type:
"passwd"

Then, you enter you old password, and a new one twice. Good to go, you log off, then try to log back in with you new password. No dice.

You brush it off, don't need to do that now, and you'll look at it later. In about an hour, you get an email from the sysadmin: You're account is hacked.

Guess where it happened? While you were in the pub dir. A malicious user placed a hacked "passwd" binary there. And, since you have "./" in your path, it executed the one in the working dir.

It's good practice that if you have scripts or binaries in your home dir, make a ~/bin directory, and add that to your path. Or else, you will have to explicitly tell it to use the binary in your current dir.

[n6hcm]

The other one is outlined in the cryptic "grep" post, where the "tic" (the character under the tilde (~) in the upper left hand corner of the keyboard has a different meaning in linux than unix. WTF?

no, it doesn't. i use this every day on my linux systems and it behaves exactly like the UNIX systems on which i learnt ages ago.

you may run a shell which doesn't support ` in the usual way, but all the mainstream shells do.

as for the "current directory in your execute path" thing, someone else correctly identified it as a security issue. you can change this behavior if you like.

[ka8ncr]

Guess where it happened? While you were in the pub dir. A malicious user placed a hacked "passwd" binary there. And, since you have "./" in your path, it executed the one in the working dir.

It's good practice that if you have scripts or binaries in your home dir, make a ~/bin directory, and add that to your path. Or else, you will have to explicitly tell it to use the binary in your current dir.

How does the malicious user get the setuid bit set? Without it, the malicious file can't actually change the password, but it can send what was entered elsewhere.

I'm still searching for the reason. Your scenario seems an interesting possibility.

Anyone have their Stevens book handy?

[KC2UGV]

Guess where it happened? While you were in the pub dir. A malicious user placed a hacked "passwd" binary there. And, since you have "./" in your path, it executed the one in the working dir.

It's good practice that if you have scripts or binaries in your home dir, make a ~/bin directory, and add that to your path. Or else, you will have to explicitly tell it to use the binary in your current dir.

How does the malicious user get the setuid bit set? Without it, the malicious file can't actually change the password, but it can send what was entered elsewhere.

I'm still searching for the reason. Your scenario seems an interesting possibility.

Anyone have their Stevens book handy?

You don't need to change the password. Just collect it.

But, the reason why your next login didn't work is due to trying the "new" password you set. And, trying to avoid a lock-out (3 times and you're out) you give up for now to move on to more pressing matters.

Even better, don't need the suid bit set. Any user can change their own password. Pass the args through to the real passwd binary. Voila! You've captured the new password, and made it invisible to the user, because in this case, the password changed, and you logged in successfully.

[ka8ncr]

Turns out we're both correct.

Shells that implicitly built large hash tables didn't have good collision avoidance and as the table became more than 50% full, it began to work like a linear search. I don't think they do it like this any longer (at least I hope not).

And giving people the ability to have something override a system command is at a minimum foolish ("why is my rm not working?") or in your cited case, dangerous.