Solaris Boot Process

The Solaris 10 OS boot process :
There are five phases, a Solaris box passes through during the boot process:
1. Boot PROM phase

This is the first phase during the boot process. As soon as a Solaris box is booted, it is controlled by the software coming from the PROM chip. This PROM software (BIOS on Intel arch. is almost a similar idea) performs the POST (Power On Self Test) and then allows the user to interact through the "ok" prompt  offered by it. PROM invokes "boot" command whether specified interactively or automatically for a reboot.

Amongst several other variables, two NVRAM variables are of importance during the boot process - "boot-device", which informs the boot command as to where to find the next stage i.e. bootblk program to continue further. Typical values of boot-device variable may include - disk, disk0 disk1, mirrordisk, net etc. These values are alias to actual device paths which can be listed using devalias, show-devs, show-disks etc. Another variable is "auto-boot?" - which is a variable that can only hold true or false. True value ensures that it boots with the default boot-device values instead of waiting for a user input at "ok" prompt.

2. Boot Program phase

3. Kernel Initialization

4. init phase

5. svc.startd phase

VTOC Boot Block and ther file system stuff - Solaris

Operating systems on Intel / IDE architecture follow a very simple way of managing partitions - they keep the first 512 bytes (0th Sector) reserved for storing partition table and the first stage of boot loader program. The partition table is a 64 byte table and since information about one partition requires 16 bytes space in it, it can store only upto 4 partition's information and thus the concept of only 4 primary partitions on such an architecture.

In Solaris, the partition information is also stored in the first sector but unlike the Intel/IDE inherent architecture, here the entire sector is used up for storing just the partition's information only. There are 0 to7 - 8 slices (partition's are known as slices in Solaris) and all their related information - type, start end cylinder number etc in kept in this table which is called as Volume Table of Contents or VTOC.


A typical Sparc based disk layout is as follows:

Let's not forget that 16 sectors make up 8 Kilobytes - 1 Block in UFS filesystem
So very first block in every slice (or a file system) is reserved for VTOC and Boot Block. It is just that they contain data in case it slice 0 and for the other slices, this block in inactive.

Slice 0
===========
1st block
VTOC - Sector 0
Boot Block - Sector 1 to Sector  15

2nd block
Primary Superblock - Sector 16 to 31


3rd block onwards

Backup Superblock, Cylinder Group Blocks, I-Node list, Data Blocks
============
In every slice (except slice 2, which represents the whole disk), the order and purpose of the blocks is same. It is just that first block is practically of no use and does not contain any data though being reserved.

Super block data reflects the health of the file system that includes - number of data blocks, cylinder blocks, size of a data block, mount point for the slice, state flag - clean, stable, active, logging or unknown.

Cylinder groups are meant for faster data access. Each file system is broken down into cylinder groups with keeping 16 (default) cylinders in a group. Disk writes are attempted to a file's data into a single cylinder group but large files can also be stored across multiple several cylinder groups.

Cylinder group block is a table within a cylinder group that defines a cylinder group - number of inodes, number of data blocks, number of directories, free blocks, free inodes, free fragments in the cylinder group, free block map, used inode map.
Cylinder group also contains a backup copy of the super block in the very beginning.  

GNU-LINUX Story

 clicking here redirects to this article.

Let's dissect the SUID Bit

Wondered what does it mean by suid wrt a file in UNIX/Linux?
Well, suid is the patented idea of Dennis Ritchie (the inventor of computer language C).

Lets keep things simple, an an executable file has an owner and a group owner like any other file or resource. When it comes to executing a file, not only the one who owns the file can run it but even the "others" can also execute it - given that they are given the execute permission on it by the owner.

Now in the first scenario, when the owner himself runs the program(file) the resultant process has two owners - real and effective. So, if the uid of the person happens to be 567, the real and effective user id's of the process will be 567 each.

In the second scenario, when the other user runs the program (the program file has to have the execute permission on it for others) and if the uid of this person is 590 then the resultant process has a real user id of 590 and the effective user id of 590.

Whenever this running process tries to access another resource like opening a new file on disk file system, the permission for such an access are tested against the effective user id of the process.

So now we know that whenever we run an executable, the process' real and effective user ids are the same as the id of the user who is running this program.

Now when the executable has an suid bit set on it, the real user id of the process would be of the person who runs the process but the effective user id would be of the person who has the file ownership of the program. So now this program can use the resources with the effective uid's user authorization as discussed above and can thus perform some task that was not possible otherwise using the id of the person who ran the program.


To understand this lets take an example:

The passwd command is an executable file and is owned by root. When run, it makes changes to a file /etc/shadow that is not even readble by any user by other means. But when any user runs the passwd command file, they are able to make changes in their respective passwords.

It is how all this works - the passwd command file is owned by root but has a suid bit set on it. When any user other than root runs the program, the process thus created, has the real user id of the person who ran it (Lets take it 567 for example) but its effective user id is of the owner of the passwd command file and that is root's id 0(zero). So whenever any user changes his password by running the password command, the process created, has the effective user id of root and thus it is able to make changes in the /etc/shadow file.

This concept makes those programs which are owned by root and also have suid bit set on them as a potential threat to the UNIX system as they can run with root privileges and can create a havoc once overwritten by some other malicious code. So one must make sure that such binary files are not left writable by mistake.
===========================================
Command to add the suid bit on an executable:

$ chmod u+S file_name

sgid bit works on the same principles, only that it deals with real/effective group users.

A Virtual X server

Recently discovered a virtual X server i.e. Xvbf. This is a server that ships along with a normal X server from Xorg www.x.org.

The X protocol says that X client produces the graphical output but X server renders it on the screen. Both of these softwares could be running on the same machines or on different machines on the top of TCP/IP protocl stack. This model of GUI is quite different than that of Windows.

Xvfb is used for testing as it does not produce a real GUI on some screen but rather stores that in a file as configured beforehand. A good basic introduction of Xvbf is given here : http://www.x.org/archive/X11R6.8.2/doc/Xvfb.1.html#sect6

Solaris related XVbf help could be found here : http://developers.sun.com/solaris/articles/solaris_graphics.html

A good article describing the need of Xvfb for running java applications is detailed here:
http://creamtec.com/products/ajaxswing/doc/setup.html