Re: New to Debian Linux - I have NASM experience under DOS 6.22

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 05/04/04 

Date: Tue, 4 May 2004 17:33:27 +0100

assemblyperson wrote:
> From on-line tutorials I have learned to write, assemble and link a
> simple NASM program under Linux. My programs would not run. I
tried
> copying them to the /bin directory. Only as root could I do that.
> Then the programs would run from any directory as root or not.
>
> Does anybody know why this worked, whether it will always work, and
> whether there is a more official or reliable way to make a NASM
programs run?
>
> Thank you for your help.

Ah, I encountered this first time I used UNIX-y systems...it seems
catastrophic or something but it ain't...it boils down to DOS /
Windows automatically including the "current directory" in the
PATH...but UNIX-y systems don't (a security thing, one presumes ;)...

Otherwise, it is _exactly the same_...under DOS, if you typed "NASM",
weren't in the directory with the NASM executable and NASM wasn't in
the "PATH" then, yup, you'd get one of those "'nasm' is not recognised
as an internal command, ..." error messages...well, basically exactly
the same idea under Linux, it's just that the "current directory" is
NOT automatically included in the search path...hence, even if you are
in the directory with NASM executable, it _still_ won't find it
because it looks through the "PATH" but, under Linux, the "current
directory" is NOT part of that PATH as it is with DOS...

How to get around this? Actually, once you understand what's wrong,
it's blissfully easy...when you _specify_ a path as part of the
command you issue, it _does_ go look in that directory for the
command...and, for every directory, there are two "special" entries
for constructing relative paths: "." which means "current directory"
and ".." which stands for "parent directory"...

Hence, just stick "./" in front of the filename...this is simply one
of the differences between the two systems here...Linux (and UNIX-y
OSes, in general) come from mainframes and were designed with
_security_ and _multi-user_ concepts at their very core...Windows and
DOS, on the other hand, have always seemed to consider such things as
"optional extras" that they aren't too particular about enforcing or
anything...

Speaking of which, there's one more thing you should also check
because _security_ comes as standard with Linux, while we'll probably
never see it ever properly introduced with Windows (I see there's yet
another Windows "worm" on the loose...again ;)...as well as the "./"
thing, you should also, of course, have "x" execution permission as
"owner" to the file...

That is, when you "ls -l" in a directory to get a "long listing" of
the files in the directory, you'll see some text at the start like
"-rw-rw-r--" or whatever...these are the security permissions on the
file...in full, "drwxrwxrwx" where "d" just means "directory" (shows
which is a file and which is a folder :)...and then the "rwx" is
"read", "write" and "execute" permissions on the file...they are
repeated three times because the first set is "owner" permissions
(whichever user creates the file is "owner"...you can see this listed
in another column in this long "ls -l" listing, if you look :)...the
next one is "group" (all users can be part of a "group" too...a simple
way to organise permissions :)...and the final "rwx" refers to the
"other / public" permissions (that is, everyone else who's not the
owner or part of the owner's "group" ;)...

To change the permissions, there's the "chmod" command...which
actually is one place where people still use octal...as the "rwx" is
basically just three bits then a single octal digit can specify
permissions...tap in "chmod", three octal digits for the various
permissions and then the file's name and (presuming you yourself have
permission to do so...but if you're the "owner" of the file - as
you're bound to be when you've just created it by running NASM for
your user account - then you will be able to do this ;) the
permissions are altered...

You'll probably find the file already automatically has the "x"
permission set but, well, this is just useful "file management" stuff
to know (say, for instance, you want some other user to be able to
wander into your home directory and pick up a certain file from there
but without dropping all your security on the other files...you can
just add the "r" permission in the right place and then they can copy
it over to their own directory or whatever :)...and, you'd be
surprised that I _have_ seen tools which stupidly didn't automatically
set the "execute" permission, even though it was a compiler and, well,
what the hell else do you want to do with the file? You kind of want
"x" before you even want "w" on executable files, generally :)...

So, really, it's not actually different other than Linux - unlike DOS
and Windows - comprehends the notion of _security_...UNIX was a
_multi-user_ system for mainframes and, hence, this stuff is
fundamentally _built-in_ to its core operations (rather than badly
tacked on by Microsoft in a panic because, yet again, a cracker's
discovered a "buffer overrun" and is spreading maliciousness all over
the internet...whereas UNIX was "multi-user" and "multi-tasking" and
"networking" from the core and the very beginning, Windows started out
as an ugly single-tasking, single-user, local-machine-only DOS
application program which couldn't even comprehend how to overlap
windows! Microsoft have eventually hacked it from every angle to try
to remedy this situation but it does still betray its origins from
time to time...why so many "buffer overrun exploits"? Simple...wasn't
that much of a problem when the code was first written because Windows
wasn't even a real OS, let alone trying to be "multi-user" over an
internet connection...but the lack of foresight from Microsoft means
the need to continually "patch" and "quickfix" and "hack out" all of
these previous bits of nasty code from when MS's policy didn't ever
include the words "security" or even "reliability"...UNIX, on the
other hand, was always "multi-user" because it ran on mainframes,
which is "multi-user" hardware (one central computer, lots of "dumb
terminals" attached :)...so "security" and "reliability" were the top
priorities...couldn't have users wandering around deleting each
other's files, couldn't have the entire system brought down because of
one stupid user executing their own program, getting a "seg fault" and
bringing down the entire machine, thereby crashing the machine for
_all_ users attached to it...hence, "security" and "reliability" were
the very _top priorities_ for UNIX-based systems from the very
beginning...Microsoft have seemingly only just looked up what the
words mean in a dictionary Tuesday last week: "ah, so _that's_ what
everyone's talking about!", said Sir Bill in that "Eureaka!" moment of
realisation that he's been peddling utter crap all this time ;)...it
doesn't let just anyone play around with someone else's files...and it
_doesn't_ presume the "current directory" unless you _TELL_ it that
this is what you want...when you're used to DOS and not used to this
scheme, it might initially seem a bit "dumb" but, really, it's nice to
know that it is actually _looking after your files_, while Windows has
just let in some "worm" completely unopposed which is sending back the
contents of your entire hard drive to someone in Romania you've no
idea about, without a single worry or care about doing that(!)...

So, when you want to run your program, do a "ls -l" to check the
"permissions"...if you see "r-x" in the first "owner" set of
permissions (and, of course, that you are the "owner" of the
file...you will be if you ran NASM in the same user account that
you're now using...basically, any file creations you do while logged
in as your username will be attributed to you as "owner" unless you
play around with commands (and, of course, have the permissions to do
that...but, if this is your home machine, then, likely, it's you who's
also the "system administrator" so you can do whatever the hell you
like, as you can sign on as "root" :) to make it otherwise :)...

Then, either type "./" before the filename...or, alternatively, you
might choose to add the directory onto the "PATH"...the latter only
really being worth the bother, though, if you need to do this very
often that it's worth the effort of adding it on...you could, for
instance, create some "MyPrograms" directory (oh, yes, I use mixed
case filenames under a UNIX OS!! Burn the witch! Burn the Witch!
Sorry, just kidding...because Linux / UNIX is _case sensitive_ with
filenames, the "convention" tends to be to always use lowercase
letters throughout, you see...just poking fun, is all...although,
ummm, yes...that's another point but I bet you already know it: Linux
is _CaseSensitive_ so make sure, also, that you're typing out the
filename exactly with respect to case...something you don't need to do
with DOS - though, the reason isn't "user-friendliness", as you might
intially imagine...DOS simply didn't store anything but UPPERCASE
characters until "long filenames" appeared so the "case insensitivity"
is actually to do with "backwards compatibility", more than trying to
be "user-friendly" or anything...I have an old DOS program that spits
out UPPERCASE file extensions but the rest is lowercase...well, it
didn't matter too much before, as DOS could only store UPPERCASE and
it got UPPERCASED before use, anyway...hence, to get around this
potential problem, Microsoft made things "case insensitive"...this
just so happens to be pretty "user-friendly" (to "Clueless Newbies",
for sure ;) that it's not fussy about case...but that wasn't really
the reason for it...the reason was yet one more Microsoft
"compatibility hack" ;) and that's where you dump all of your programs
and then you could add it onto your "PATH"...depends, though, of
course, on how you prefer to work and store your files...the "./" is
much easier but you would have to add in those extra two characters
every time :)...

Also, of course, if you like being silly as I frequently do, then
"../programs/../programs/././" could also be used, where your
directory is called "programs"...or you could type
"/home/assemblyperson/programs/" (presuming your Linux username is
"assemblyperson" too ;) as an absolute path to the program as
well...well, okay, very silly but helps clarify what's going on a
little, perhaps...a filename without a path attached is searched for
in the "PATH" (and _only_ in the "PATH" :)...stick on a path, though,
and you're telling it where to look so it will go look there for
you...

And another alternative, if you're thinking "I liked it the old DOS
way myself", then, well, you could also do as DOS automatically does
(without asking) and add "." at the front of your "PATH"
variable...then it'll copy the DOS scheme of looking in the current
directory first before looking elsewhere...of course, the security
loophole you're creating is upon your own head...that is, with the
"always search the current directory first" DOS scheme, there's a
potential "security loophole" in dropping files with certain names
into certain places and making other files execute than should be
executed...for instance, if you were to have a file called "nasm" in
the directory you're working from then you might _think_ you're
getting NASM - and if it's a naughty malicious program then it'll pop
up text on the screen to make you continue to think you're running
NASM - but it's actually some other file..."okay", you're thinking,
"but I can see that 'nasm' file in the listing...hardly a very good
way to get around security, is it?"...ah, but what applies to you
here, also applies to shell scripts and other programs and so forth
throughout the system...so, as a very contrived example, say "nasm" -
it doesn't but, for sake of argument, let's pretend it does - executes
a "bash" shell as part of its processing to run some "shell
script"...well, a naughty malicious program could just call itself
"bash" and drop itself into what NASM takes as being its "current
directory"...I think you're starting to get the security problem, yes?
The _naughty program_ gets executed in place of the _real_ shell
program that NASM wanted...a _sneaky_ naughty program could even pass
things trhough back and forth between the real programs and keep up
the pretence that nothing is wrong and no-one's the wiser that it's
getting execution all the time...and now you can fully appreciate
_why_ Linux / UNIX distributions almost always _exclude_ the current
directory - "." - from the PATH by default...it's just asking for
trouble and naughtiness...rather, _only_ look where you're told and
_nowhere else_...specifically have a "/bin" directory for system
commands and utilities that, yup, _that_ is the place to go searching
for any "naughty programs" trying to get up to mischief...on Windows?
Oh boy, have you _seen_ the maze of thousands of DLLs and hidden
folders and goodness knows what else in the "Windows" folder? A
"naughty program" doesn't even need to attempt to disguise itself at
all because no-one'll be able to find it amongst all those files and
folders and hidden folders!!

[ DISCLAIMER: The above is only to explain the potential security
loophole...creating malicious stuff based on this, knowing that
Windows is potentially vurnerable to such things just _sucks_...sucks
big-time...no smiles for you, only hexes cast upon you for being very
mean and nasty, and I'm not talking about number systems there...it's
not big, it's not clever...it's just the biggest sucky suck-suck in
all suckingdom and whoever does it is just a big sucky turd! Don't
like Windows? Then _do good stuff for Linux_ to promote it more and
more as a viable alternative for _everyone_...aren't all those poor
Windows users already suffering enough without being made to suffer
more? The best way to attack Windows is just to make Linux and other
OSes look so damned good, that Windows just looks totally silly..."two
birds with one stone": Windows just looks silly and Linux becomes such
a good _free_ platform that you'd have to be insane to look anywhere
else and even the "Clueless Newbies" get the hint and take the
"exodus" away from Windows, whether "pre-installed" or not ;)... ]

Oh, which is the last bit of difference between UNIX and DOS to drop
in here...filenames starting with a "." are excluded from listings and
are "hidden files" unless you specifically ask it to show them...DOS
uses an attribute rather than a filename convention...perhaps the lone
place here where DOS might have the better idea...but, then, UNIX came
first...DOS is a crippled knock-off copy of an OS that itself was a
crippled knock-off copy of UNIX...being created later, you'd kind of
expect DOS to have a few more "extensions" than just this small
thing...but then, as I've always said, the PC was originally a bit of
a "backwards step" technologically, compared to everything else around
it...

Anyway, yeah, just stick "./" in front of the filename or change the
path (like DOS, type "set" to have a look at your environment
variables and current search path...and, of course, don't forget the
good old "man" and "info" pages, as it all comes with extensive
built-in help :)...and, also, watch those permissions (although,
you'll be able to tell the difference because the error message comes
up differently: "access denied" rather than "file not found", so to
speak ;), as they can play a part (but should generally be set
correctly, anyway :)...

Ah, as I was saying to the LuxAsm team about X-Windows: "because
you've been using a 'toy' for so long (DOS / Windows ;), you may
initially find aspects of Linux / X disconcertingly different...but,
as the Hitchhiker's Guide reminds us: 'Don't panic!'...this is just
because you're now learning how things _should_ be done, rather than
learning how Microsoft _hacked_ their way around things badly with
their little 'toys'" ;)...

Beth :)