I'm not able to get difference between build and compile. Are they same? how exactly linking works? What exactly .so file and .o file contains and how I am supposed to use them? These all files I see everyday but I don't know exactly what they contain. Can anyone suggest some tutorial to clearly tell these processes?
Linux – Build, link processes in linux
linux
Related Solutions
There are countless reasons one might try to compromise a system's security. In broad strokes:
- To use the system's resources (e.g. send spam, relay traffic)
- To acquire information on the system (e.g. get customer data from an ecommerce site).
- To change information on the system (e.g. deface a web site, plant false information, remove information)
Only sometimes do these things require root access. For example, entering a malformed search query on a site that doesn't properly sanitize user input can reveal information from the site's database, such as user names / passwords, email addresses, etc.
Many computer criminals are just "script kiddies"; i.e. people who don't actually understand systems security, and may not even code, but run exploits written by others. These are usually pretty easily defended against because they don't have the ability to adapt; they are limited to exploiting known vulnerabilities. (Though they may leverage botnets -- large groups of compromised computers -- which can mean a danger of DDoS attacks.)
For the skilled attacker, the process goes something like this:
Figure out what the goal is, and what the goal is worth. Security -- maintaining it or compromising it -- is a risk/reward calculation. The riskier and more costly something will be, the more inticing the reward must be to make an attack worthwhile.
Consider all the moving parts that effect whatever the goal is -- for example, if you want to send spam, you could attack the mail server, but it may make more sense to go after a different network-facing service, as all you really need is use of the target's net connection. If you want user data, you'd start looking at the database server, the webapp and web server that have the ability to access it, the system that backs it up, etc.
Never discount the human factor. Securing a computer system is far easier than securing human behavior. Getting someone to reveal information they shouldn't, or run code they shouldn't, is both easy and effective. In college, I won a bet with a friend that involved breaking into his uber-secure corporate network by donning a revealing outfit and running into a lecherous Vice President -- my friend's technical expertise far outweighed mine, but nothing trumps the power of a 17yo co-ed in a short skirt!
If you lack boobs, consider offering up a pointless game or something that idiots will download for fun without considering what it really might be doing.
Look at each part you've identified, and consider what it can do, and how that could be tweaked to do what you want -- maybe the help desk resets passwords for users frequently without properly identifying the caller, and calling them sounding confused will get you someone else's password. Maybe the webapp isn't checking what is put in the search box to make sure it isn't code before sticking it in a function it runs. Security compromises usually start with something purposely exposed that can be made to behave in a way it shouldn't.
Linux distributions use the FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html
You can also try man hier.
I'll try to sum up answers your questions off the top of my head, but I strongly suggest that you read through the FHS:
- /bin is for non-superuser system binaries
- /sbin is for superuser (root) system binaries
- /usr/bin & /usr/sbin are for non-critical shared non-superuser or superuser binaries, respectively
- /mnt is for temporarily mounting a partition
- /media is for mounting many removable media at once
- /dev contains your system device files; it's a long story :)
- The /usr folder, and its subfolders, can be shared with other systems, so that they will have access to the same programs/files installed in one place. Since /usr is typically on a separate filesystem, it doesn't contain binaries that are necessary to bring the system online.
- /root is separate because it may be necessary to bring the system online without mounting other directories which may be on separate partitions/hard drives/servers
- Yes, /etc stands for "et cetera". Configuration files for the local system are stored there.
- /opt is a place where you can install programs that you download/compile. That way you can keep them separate from the rest of the system, with all of the files in one place.
- /proc contains information about the kernel and running processes
- /var contains variable size files like logs, mail, webpages, etc.
To access a system, you generally don't need /var, /opt, /usr, /home; some of potentially largest directories on a system.
One of my favorites, which some people don't use, is /srv. It's for data that is being hosted via services like http/ftp/samba. I've see /var used for this a lot, which isn't really its purpose.
Best Answer
The term "build" is usually used to mean the whole process that starts off with a set of source code files and other resources, and ends up with a set of executables, shared libraries (and possibly other resources).
This can involve quite a lot of steps like special pre-processors (
mocfor Qt code for example), code generators (flex/yaccorbisonfor instance), compilation, linking, and possibly post-processing steps (e.g. buildingtar.gzorrpmfiles for distribution).For C and C++ (and related languages), compilation is the thing that transform source files (say
.cfiles for C code) into object files (.o). These object files contain the machine code generated by the compiler for the corresponding source code, but aren't final products - in particular, external function (and data) references are not resolved. They are "incomplete" in that sense.Object files are sometimes grouped together into archives (
.afiles), also called static libraries. This is pretty much just a convenience way of grouping them together.Linking takes (usually several) object files (
.oor.a) and shared libraries, combines the object files, resolves the references (mainly) between the object files themselves and the shared libraries, and produces executables that you can actually use, or shared libraries (.so) that can be used by other programs or shared libraries.Shared libraries are repositories of code/functions that can be used directly by other executables. The main difference between dynamic linking against a shared library, and (static) linking an object or archive file in directly, is that shared libraries can be updated without rebuilding the executables that use them (there are a lot of restrictions to this though).
For instance, if at some point a bug is found in an OpenSSL shared library, the fix can be made in that code, and updated shared libraries can be produced and shipped. The programs that linked dynamically to that shared library don't need to re-build to get the bug-fix. Updating the shared library automatically fixes all its users.
Had they linked with an object file instead (or statically in general), they would have had to rebuild (or at least re-link) to get the fix.
A practical example: say you want to write a program - a fancy command line calculator - in C, that has command line history/editing support. You'd write the calculator code, but you'd use the
readlinelibrary for the input handling.You could split your code in two parts: the math functions (put those functions in
mathfuncs.c), and the "main" calculator code that deals with input/output (say inmain.c).Your build would consist in:
Compile mathfuncs.c (
gcc -o mathfuncs.o -c mathfuncs.c,-cstands for "compile only")mathfuncs.onow contains your compiled math functions, but isn't "executable" - it's just a repository of function code.Compile your frontend (
gcc -o main.o -c main.c)main.ois likewise just a bunch of functions, not runnableLink your calculator executable, linking with
readline:Now you have a real executable that you can run (
supercalc), that depends on thereadlinelibrary.Build an
rpmpackage with all the executable and shared library (and header) in it. (The.ofiles, being temporary build products and not final products, aren't usually shipped.)With this, if a bug is found in
readline, you won't have to rebuild (and re-ship) your executable to get the fix - updatinglibreadline.sois all that is required. But if you find a bug inmathfuncs.c, you'll need to re-compile it and re-linksupercalc(and ship a new version).