Lets Compile the KERNEL

step 1 Get source from http://www.kernel.org/pub/linux/kernel/v2.6/ say linux-2.6.18.6.bz2
step 2 unzip it $tar -jxvf linux-2.6.18.6.bz2 , cd to the dir linux-2.6.18.6
or use bunzip2
step 3 Configuration : it saves in .config file
a use oldconfig file cp /boot/config-2.6.16 .config
make oldconfig
make congif or make menuconfig (pseudo graphical)
or make xconfig (graphical)

step 4 make
step 5 make modules_install (copies modules to /lib/modules/VERSION)
step 6 make install (copies vmzlinux image , initrd and system map file to /boot )
also modifies grub.conf(/boot/grub/menu.lst) makes entry for this new kernel

Top kernel Makefile does folllowing things
Reads configuration from .config.
Updates include/linux/version.h
Sets symlink include/asm to our architecture.
Builds include/linux/autoconf.h
Builds include/linux/config.h
Invokes make –f scripts/Makefile.build obj=subdir for each subdirectory

Giving ordinary users root privileges

Many times on a multi-user system it would be nice to allow particular users to do things that require root privileges without having to give them the root password. There are several tools which will solve this problem, the most well known tool for this purpose is called sudo.

sudo is a portable application for giving users selectively increased permissions.

The Debian sudo package is available for all the releases and will setup a minimal configuration file when it is installed.

sudo is configured entirely through the file /etc/sudoers. This file controls the commands which users are allowed to run.

Whilst the program is flexiable enough to allow users to be given the ability to run commands as any local user it is typically used to give root privileges for commands.

This is the default sudoers configuration:

# sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL) ALL

The configuration is blank here, the last line being the only one which isn't a comment.

(The last line basically says that the root user can run any command).

To give a local user the ability to shut down a computer you would need to add two sections. One to define the shutdown command which you wished the user to be able to execute - the second to define the user(s) which could run this command.

First in the command section we define a new alias which represents the shutdown command:

# Cmnd alias specification
Cmnd_Alias SHUTDOWN = /sbin/shutdown

Then in the users section we will define a user who will be able to execute this command:

skx ALL = SHUTDOWN

This says that the user "skx" on the machine "ALL" (ie. this machine) can run the command defined as SHUTDOWN.

This user can now shutdown the machine by running:

skx@lappy:~$ sudo shutdown -h now

The sudo program will prompt the user for their own password, not root's, and then execute the command. The command will be logged via syslog.

If you wish you can setup sudo so that users don't even need to enter their own password, by using "NOPASSWD:" as follows:

skx ALL = NOPASSWD: SHUTDOWN

As you can see "ALL" is defined for us, here we see it as representing all hostnames, but you can also use it to define all commands.

The following setting will allow the local user skx to run any command as root - this is very very permissive and is equivilent to allowing them to have root privileges.

skx ALL = ALL

In a group setting you might want to define a group of people who are able to perform some administration without knowing the root password. This can be achieved by defining a group:

# User alias specification
User_Alias ADMINS = skx,bob,chris

# Cmnd alias specification
Cmnd_Alias SHUTDOWN = /sbin/shutdown
Cmnd_Alias APT = /usr/bin/apt-get, /usr/bin/dpkg

# full time sysadmins can run updates and shutdown the machine.
ADMINS ALL = APT, SHUTDOWN

This example shows that three users, skx, bob, and chris, can update the machine using either apt or dpkg, and shutdown the machine. Any of these operations can be conducted without having the root password.

Note allowing users to run apt and dpkg is equivilent to giving a user root privileges, as packages can be installed which will subvert the system.

Even in a single user system sudo is worth using, the following settings, for example, will allow you to run any command as root - without having to use su or constantly type in your root password:

# User alias specification
User_Alias OWNER = skx

# User privilege specification
OWNER ALL= NOPASSWD: ALL

ROOT Definition

root Definition



root, which is also referred to as the root user, the administrative user, the system administrator, the root account and the superuser, is the user name or account that has access to all commands and files on a Unix-like operating system.

The word root also has several additional, related meanings when used as part of other terms, and thus it can be a source of confusion to people new to Unix-like systems.

One of these is the root directory, which is the top level directory on a system, i.e., the directory in which all other directories, including their subdirectories, and files reside. The root directory is designated merely by a forward slash ( / ).

Another is /root, a directory that should not to be confused with the root directory. /root is the root user's home directory, and it is a subdirectory of the root directory, as indicated by the forward slash that begins its name. A home directory is the primary repository of a user's files, including that user's configuration files, and it is usually the directory that a user is put into when it logs into a system. Home directories for users other than root are by default created in the /home directory, which is another standard subdirectory of the root directory.

Root privileges are the powers that the root user has on the system. The root user is the most privileged user on the system and has absolute power over it (i.e., complete access to all files and commands). Among root's powers are the ability to modify the system in any way desired and to grant and revoke any permissions (i.e., the ability to access specific files and directories) for any other users, including any of those by default reserved for root.

A rootkit is a set of tools used by an intruder, after breaking into a computer and obtaining root access, in order to maintain such access, hide traces of it and exploit it.

The use of the term root for the all-powerful administrative user may have arisen from the fact that root is the only account having write permissions (i.e., permission to write data to files) in the root directory. The root directory, in turn, takes its name from the fact that the filesystems (i.e., the entire hierarchy of directories that is used to organize files) in Unix-like operating systems have been designed with a tree-like (although inverted) structure in which all directories branch off from a single directory which is analogous to the root of a tree.

Unix-like operating systems were designed from the very beginning as multi-user systems because personal computers did not yet exist and each user was connected to the mainframe computer (i.e., a large, centralized computer) via a dumb (i.e., very simple) terminal. Thus it was necessary to have a mechanism for separating and protecting the files of the individual users while allowing them to use the system simultaneously. It was also necessary to have a mechanism that enabled a system administrative to perform such tasks as entering user directories and files to correct individual problems, granting and revoking powers for ordinary users and and accessing critical system files to repair or upgrade the system.
Every user is automatically assigned an identification number, termed a user ID or UID, by a Unix-like system, and this number is used by the system instead of the user name to identify the user. Root always has a UID of zero. This can be verified by logging in as root (if using a home computer or other system that permits this operation) and issuing the following command:

echo $UID

It can also be seen by looking at /etc/passwd, which is the configuration file for user data. This file can be viewed (by default by all users) by using the cat command, which is commonly employed to read files, i.e.,

cat /etc/passwd | less

The output of cat /etc/passwd can be piped (i.e., transferred) to the less command to allow it to be read one screenful at a time, which is useful if the file is a long one. The line of output for root will look something like root:x:0:0:root:/root:/bin/bash. The first column shows the user name and the third column shows the UID, which can clearly be seen to be zero.

The permissions system in Unix-like operating systems is a key component in the inherently outstanding security of such systems. It is set by default to restrict access to critical parts of the system and to directories and files belonging to other users for all users except for the account that has a UID of zero in /etc/passwd. This means absolute control over the system for the root user.

Thus, it can be very tempting for users new to Unix-like operating systems, especially those who are accustomed to systems with a weak permissions system or without any permissions system (e.g., Microsoft Windows or the older versions of the Macintosh), to bypass this system by logging directly into the root account and staying there. Although this provides momentary relief, it should be avoided and ordinary work on the system should be done via a user account.

This is because it is very easy to damage a Unix-like system when using it as root -- much easier than to damage most other types of operating systems. The designers of most other systems devised methods of protecting the system and data to compensate for the lack of a robust permissions system.

An important principle of Unix-like operating systems is to provide maximum flexibility to configure the system, and thus the root user is fully empowered. Unix-like systems assume that the root user knows exactly what it is doing and that only such individuals will be using the root account. Thus, there is virtually no safety net for the root user in the event of a careless error, such as damaging or deleting a critical system file (which could make the entire system unusable).

Adding to the danger of using the system as root is the fact that all processes (i.e., instances of programs in execution) started by the root user have root privileges. Programming errors are common, and even well-tested programs can contain security-related errors that can eventually allow an attacker to obtain control of a system when programs are run with root privileges rather than by an ordinary user with limited privileges.

Although operating systems are designed with mechanisms to prevent users from damaging data or the system, these mechanisms function only if the system is used as intended. A critical mechanism to keep users from damaging Unix-like systems is the requirement that the root account not be used except when absolutely necessary, even by system administrators. Even they should not log into the system routinely as root.

Rather, they should log into the system with their ordinary user (i.e., those without root privileges) accounts and then use other commands, such as su, kdesu and sudo, that allow providing root privileges only as needed and without requiring a new login.

For example, to become root with su merely requires typing

su

at the command line (i.e., in the all-text mode), pressing the ENTER key and supplying the root password. The account of the previous user can be returned to by hitting CTRL and d simultaneously or by typing the word exit and then pressing the ENTER key.

A convenient option, and one that can add to security, is -c, which tells su to execute the command as root that is typed directly following it on the same line and then immediately return to the account of the former user after the command has completed execution or after any program that it has launched has been closed.

Tasks that require root privileges include moving files or directories into or out of system directories (i.e., directories that are critical to the functioning of the operating system), and copying files into system directories, granting or revoking user privileges, some system repairs and the installation of some application programs. It is not necessary to be root to be able to read most configuration files and documentation files in system directories, although it is necessary to be root to modify them.

Root privileges are usually required for installing software in RPM (Red Hat Package Manager) package format because of the need to write to system directories. If software is being compiled from source code, however, it can usually be configured to install and run from a user's home directory, in which case root privileges are not needed to install it. Source code is the version of software as it is originally written (i.e., typed into a computer) by a human in plain text (i.e., human readable alphanumeric characters). It is converted by a compiler into machine code, which is directly understandable by a computer's processor, so that the program can be run. Compiling software does not require root privileges when done in a user's home directory, and, in fact, it should not be done as root for security reasons.

On large systems used by businesses and other organizations, there will likely be several system administrators. Each will have its own account in which it will ordinarily work (and the activities of which will be automatically recorded in system logs for security and repair purposes) but will also have access to the root account for use when necessary. The system administrator(s) might grant limited root privileges to some individuals, such as assistant administrators.

set user id and set group id

when we give chmod 0777 file first no is for suid sgid n sticky bit n their combination
rest three are for ugo

111 left most for suid
middle for sgid
lst right for sticky

0 000 none
1 001 sticky
2 010 sgid
3 011 sgid + stick
4 100 suid
5 101 suid + stick
6 110 suid + sgid
7 111 suid + sgid + sticky bit


so chmod 4644 file result in 100 110 100 100 i.e rwSr--r--
chmod 6654 file result in 110 110 101 100 i.e rwSr-Sr--
chmod 3646 file result in 011 110 100 110 i.e rw-r-SrwT

The Boot Process

Boot process:

1. A boot loader finds the kernel image on the disk, loads it into memory, and starts it.
2. The kernel initializes the devices and its drivers.
3. The kernel mounts the root filesystem.
4. The kernel starts a program called init.
5. init sets the rest of the processes in motion.
6. The last processes that init starts as part of the boot sequence allow you to log in.

Identifying each stage of the boot process is invaluable in fixing boot problems and understanding the system as a whole. To start, zero in on the boot loader, which is the initial screen or prompt you get after the computer does its power-on self-test, asking which operating system to run. After you make a choice, the boot loader runs the Linux kernel, handing control of the system to the kernel.

There is a detailed discussion of the kernel elsewhere in this book from which this article is excerpted. This article covers the kernel initialization stage, the stage when the kernel prints a bunch of messages about the hardware present on the system. The kernel starts init just after it displays a message proclaiming that the kernel has mounted the root filesystem:

VFS: Mounted root (ext2 filesystem) readonly.

Soon after, you will see a message about init starting, followed by system service startup messages, and finally you get a login prompt of some sort.

NOTE On Red Hat Linux, the init note is especially obvious, because it "welcomes" you to "Red Hat Linux." All messages thereafter show success or failure in brackets at the right-hand side of the screen.

Most of this chapter deals with init, because it is the part of the boot sequence where you have the most control.

init

There is nothing special about init. It is a program just like any other on the Linux system, and you'll find it in /sbin along with other system binaries. The main purpose of init is to start and stop other programs in a particular sequence. All you have to know is how this sequence works.

There are a few different variations, but most Linux distributions use the System V style discussed here. Some distributions use a simpler version that resembles the BSD init, but you are unlikely to encounter this.

Runlevels

At any given time on a Linux system, a certain base set of processes is running. This state of the machine is called its runlevel, and it is denoted with a number from 0 through 6. The system spends most of its time in a single runlevel. However, when you shut the machine down, init switches to a different runlevel in order to terminate the system services in an orderly fashion and to tell the kernel to stop. Yet another runlevel is for single-user mode, discussed later.

The easiest way to get a handle on runlevels is to examine the init configuration file, /etc/inittab. Look for a line like the following:

id:5:initdefault:

This line means that the default runlevel on the system is 5. All lines in the inittab file take this form, with four fields separated by colons occurring in the following order:

A unique identifier (a short string, such as id in the preceding example)

The applicable runlevel number(s)

The action that init should take (in the preceding example, the action is to set the default runlevel to 5)

A command to execute (optional)

There is no command to execute in the preceding initdefault example because a command doesn't make sense in the context of setting the default runlevel. Look a little further down in inittab, until you see a line like this:

l5:5:wait:/etc/rc.d/rc 5

This line triggers most of the system configuration and services through the rc*.d and init.d directories. You can see that init is set to execute a command called /etc/rc.d/rc 5 when in runlevel 5. The wait action tells when and how init runs the command: run rc 5 once when entering runlevel 5, and then wait for this command to finish before doing anything else.

There are several different actions in addition to initdefault and wait, especially pertaining to power management, and the inittab(5) manual page tells you all about them. The ones that you're most likely to encounter are explained in the following sections.

respawn

The respawn action causes init to run the command that follows, and if the command finishes executing, to run it again. You're likely to see something similar to this line in your inittab file:

1:2345:respawn:/sbin/mingetty tty1

The getty programs provide login prompts. The preceding line is for the first virtual console (/dev/tty1), the one you see when you press ALT-F1 or CONTROL-ALT-F1. The respawn action brings the login prompt back after you log out.

ctrlaltdel

The ctrlaltdel action controls what the system does when you press CONTROL-ALT-DELETE on a virtual console. On most systems, this is some sort of reboot command using the shutdown command.

sysinit

The sysinit action is the very first thing that init should run when it starts up, before entering any runlevels.

How processes in runlevels start

You are now ready to learn how init starts the system services, just before it lets you log in. Recall this inittab line from earlier:

l5:5:wait:/etc/rc.d/rc 5

This small line triggers many other programs. rc stands for run commands, and you will hear people refer to the commands as scripts, programs, or services. So, where are these commands, anyway?

For runlevel 5, in this example, the commands are probably either in /etc/rc.d/rc5.d or /etc/rc5.d. Runlevel 1 uses rc1.d, runlevel 2 uses rc2.d, and so on. You might find the following items in the rc5.d directory:

S10sysklogd       S20ppp          S99gpm
S12kerneld        S25netstd_nfs   S99httpd
S15netstd_init    S30netstd_misc  S99rmnologin
S18netbase        S45pcmcia       S99sshd
S20acct           S89atd
S20logoutd        S89cron 

The rc 5 command starts programs in this runlevel directory by running the following commands:

S10sysklogd start
S12kerneld start
S15netstd_init start
S18netbase start
...
S99sshd start 

Notice the start argument in each command. The S in a command name means that the command should run in start mode, and the number (00 through 99) determines where in the sequence rc starts the command.

The rc*.d commands are usually shell scripts that start programs in /sbin or /usr/sbin. Normally, you can figure out what one of the commands actually does by looking at the script with less or another pager program.

You can start one of these services by hand. For example, if you want to start the httpd Web server program manually, run S99httpd start. Similarly, if you ever need to kill one of the services when the machine is on, you can run the command in the rc*.d directory with the stop argument (S99httpd stop, for instance).

Some rc*.d directories contain commands that start with K (for "kill," or stop mode). In this case, rc runs the command with the stop argument instead of start. You are most likely to encounter K commands in runlevels that shut the system down.

Adding and removing services

If you want to add, delete, or modify services in the rc*.d directories, you need to take a closer look at the files inside. A long listing reveals a structure like this:

lrwxrwxrwx . . . S10sysklogd -> ../init.d/sysklogd
lrwxrwxrwx . . . S12kerneld -> ../init.d/kerneld
lrwxrwxrwx . . . S15netstd_init -> ../init.d/netstd_init
lrwxrwxrwx . . . S18netbase -> ../init.d/netbase
... 

The commands in an rc*.d directory are actually symbolic links to files in an init.d directory, usually in /etc or /etc/rc.d. Linux distributions contain these links so that they can use the same startup scripts for all runlevels. This convention is by no means a requirement, but it often makes organization a little easier.

To prevent one of the commands in the init.d directory from running in a particular runlevel, you might think of removing the symbolic link in the appropriate rc*.d directory. This does work, but if you make a mistake and ever need to put the link back in place, you might have trouble remembering the exact name of the link. Therefore, you shouldn't remove links in the rc*.d directories, but rather, add an underscore (_) to the beginning of the link name like this:

mv S99httpd _S99httpd

At boot time, rc ignores _S99httpd because it doesn't start with S or K. Furthermore, the original name is still obvious, and you have quick access to the command if you're in a pinch and need to start it by hand.

To add a service, you must create a script like the others in the init.d directory and then make a symbolic link in the correct rc*.d directory. The easiest way to write a script is to examine the scripts already in init.d, make a copy of one that you understand, and modify the copy.

When adding a service, make sure that you choose an appropriate place in the boot sequence to start the service. If the service starts too soon, it may not work, due to a dependency on some other service. For non-essential services, most systems administrators prefer numbers in the 90s, after most of the services that came with the system.

Linux distributions usually come with a command to enable and disable services in the rc*.d directories. For example, in Debian, the command is update-rc.d, and in Red Hat Linux, the command is chkconfig. Graphical user interfaces are also available. Using these programs helps keep the startup directories consistent and helps with upgrades.

HINT: One of the most common Linux installation problems is an improperly configured XFree86 server that flicks on and off, making the system unusable on console. To stop this behavior, boot into single-user mode and alter your runlevel or runlevel services. Look for something containing xdm, gdm, or kdm in your rc*.d directories, or your /etc/inittab.

Controlling init

Occasionally, you need to give init a little kick to tell it to switch runlevels, to re-read the inittab file, or just to shut down the system. Because init is always the first process on a system, its process ID is always 1.

You can control init with telinit. For example, if you want to switch to runlevel 3, use this command:

telinit 3

When switching runlevels, init tries to kill off any processes that aren't in the inittab file for the new runlevel. Therefore, you should be careful about changing runlevels.

When you need to add or remove respawning jobs or make any other change to the inittab file, you must tell init about the change and cause it to re-read the file. Some people use kill -HUP 1 to tell init to do this. This traditional method works on most versions of Unix, as long as you type it correctly. However, you can also run this telinit command:

telinit q

You can also use telinit s to switch to single-user mode.

Shutting down

init also controls how the system shuts down and reboots. The proper way to shut down a Linux machine is to use the shutdown command.

There are two basic ways to use shutdown. If you halt the system, it shuts the machine down and keeps it down. To make the machine halt immediately, use this command:

shutdown -h now

On most modern machines with reasonably recent versions of Linux, a halt cuts the power to the machine. You can also reboot the machine. For a reboot, use -r instead of -h.

The shutdown process takes several seconds. You should never reset or power off a machine during this stage.

In the preceding example, now is the time to shut down. This argument is mandatory, but there are many ways of specifying it. If you want the machine to go down sometime in the future, one way is to use +n, where n is the number of minutes shutdown should wait before doing its work. For other options, look at the shutdown(8) manual page.

To make the system reboot in 10 minutes, run this command:

shutdown -r +10

On Linux, shutdown notifies anyone logged on that the machine is going down, but it does little real work. If you specify a time other than now, shutdown creates a file called /etc/nologin. When this file is present, the system prohibits logins by anyone except the superuser.

When system shutdown time finally arrives, shutdown tells init to switch to runlevel 0 for a halt and runlevel 6 for a reboot. When init enters runlevel 0 or 6, all of the following takes place, which you can verify by looking at the scripts inside rc0.d and rc6.d:

1. init kills every process that it can (as it would when switching to any other runlevel).

The initial rc0.d/rc6.d commands run, locking system files into place and making other preparations for shutdown.

The next rc0.d/rc6.d commands unmount all filesystems other than the root.

Further rc0.d/rc6.d commands remount the root filesystem read-only.

Still more rc0.d/rc6.d commands write all buffered data out to the filesystem with the sync program.

The final rc0.d/rc6.d commands tell the kernel to reboot or stop with the reboot, halt, or poweroff program.

The reboot and halt programs behave differently for each runlevel, potentially causing confusion. By default, these programs call shutdown with the -r or -h options, but if the system is already at the halt or reboot runlevel, the programs tell the kernel to shut itself off immediately. If you really want to shut your machine down in a hurry (disregarding any possible damage from a disorderly shutdown), use the -f option.