Burning an ISO File to Disc at the Command Line 433

Verifying the checksums

Verifying a file’s checksum is like comparing fingerprints. If the fingerprints match, it’s likely that the download was successful. To verify the checksums of the ISO images you’ve downloaded, follow these steps:

1. Click the Back button on your browser to return to the first Fedora download page. Below the link to the ISO images, look for the names of the discs you’ve downloaded.

Each name is followed by an md5 checksum:

yarrow-i386-disc1.iso (md5sum: 76ef22495d186580e47efd8d7a65fe6b)

2. Write down the three checksums; you’ll need them to compare to your computed results.

3. Open a terminal window and cd to the directory containing the downloaded ISO images.

4. Use the following command to calculate the checksum for the first disc image:

$ md5sum yarrow-i386-disc1.iso

5.Compare the result to the checksum from the Fedora Web site.

The checksums should match. If they don’t, download the file again.

6.Repeat the process for the other disc files.

When you have three ISO files with good checksums, you’re ready to burn the Fedora CDs! See the next section for details.

Burning an ISO File to Disc at the Command Line

If you have access to a graphical environment, you’ll find easy-to-use tools that help you make CDs or DVDs with a few clicks of the mouse. But the easiest way to burn an ISO image onto a disc is to hit the command line.

Before you burn an ISO image, you need to find the identity of your CD or DVD drive and then run a test burn. When those steps are complete, you’re ready to burn the discs.

The cdrecord package is included in the standard Fedora distribution. It is part of the Sound and Video package and included in most installations by default.

Finding the identity of your drive

Before you can burn the ISO file to disc, you need to find the identity of your CD drive:

1. Open a terminal window and enter the following command:

$ cdrecord --scanbus

The results look something like this:

scsibus1:

1,0,0 100) ‘TEAC’ ‘DW-224E ‘ ‘F.0A’ CDR

1,1,0 101) *

1,2,0 102) *

1,3,0 103) *

1,4,0 104) *

1,5,0 105) *

1,6,0 106) *

1,7,0 107) *

2. Find your drive in the list. If you see more than one device in the list, choose your drive by its model name. The first three comma-separated numbers make up the drive identifier. Write down the drive ID because you’ll need it in a moment.

Running a test burn

A test burn does everything but turn the laser on. It tests the system speed and determines whether the image will fit on a disc. Basically, it prevents you from making a shiny coaster.

434 Technique 56: Burning CD-Rs without Getting Burned

To run a test burn, move to the directory containing the ISO disc images and enter the following command:

$cdrecord --dummy dev=1,0,0 yarrow-i386- disc1.iso

Use the device identifier that you discovered in the previous section to identify the drive in the command. The test results print to screen, displaying statistics and errors about the burn.

The most common error you’re likely to encounter is a buffer underrun. A buffer underrun means your computer wasn’t able to feed data to the burner quickly enough to keep up with the drive. Your computer may be too busy or too slow to burn a CD at the maximum rate supported by your recorder. If you get a buffer underrun error, run another test record, but set the speed to half of the speed listed in the statistics of the test burn:

$cdrecord --dummy dev=1,0,0 speed=8 yarrow-i386-disc1.iso

If you still have buffer underrun errors, halve the speed and try again. Don’t forget to stop any unnecessary programs running on your system.

Burning the distribution discs

When you get a successful result set from the test burn, take --dummy out of the command line and let the burning begin:

$cdrecord -eject dev=1,0,0 yarrow-i386- disc1.iso

Add the -eject flag to eject the disc when the write is complete.

cdrecord displays a nine-second countdown before turning on the laser. When the drive is finished writing, the disc ejects. Repeat the steps to make discs 2 and 3 of the Fedora distribution, and your set is complete!

Creating an ISO Image

at the Command Line

You can put data on a CD or DVD two ways: You can just burn the bytes that make up the data straight onto the disc, or you can create a file system to hold the data and then burn the file system onto the disc.

Here’s an example to clarify what you get with each option. Say you want to store your e-mail inbox on CD. Typically, a mailbox is made up of two files: The mail messages are stored in one file (inbox.mbox), and the index is stored in a separate file (inbox.idx). You could simply stream both files onto the CD, one right after the other, but you’ll find this method has a few disadvantages down the road:

You’ll lose useful information. First, you would lose the filenames — the filename is part of the file system, not part of the file content. In fact, you would lose the boundary between the two files. If you stream two files to a CD, you can’t tell where one file ends and the other begins. You would also lose the creation and modification dates for the file, the owner and group IDs, and the file permissions — that information is stored in the file system, not in the file.

You can’t mount a raw data disc later on. You’ll have to stream the data back off the disc instead and re-create the two data files yourself.

You can’t really tell what’s on the disc if you forget to label it properly. This is one of the biggest disadvantages to writing raw data.

By creating an ISO image so that the file system travels with the data, you’ll reap all sorts of timesaving benefits. The alternative is to create a mini–file system that holds the two files and then burn the file system to disc. The filenames are preserved, the owner and group IDs are preserved, the permissions are preserved, and the boundary between the two files is managed by the file system. You can mount a CD that contains a file system.

Burning CDs without Making an ISO First

435

There are still a few legitimate reasons to create a raw-data CD (in fact, we show you how to do that in the next section), but in most cases, you should create a file system first.

Although you can write just about any type of file system to a CD (ext2, resierfs, xfs), most computers expect to find an ISO 9660 (or ISO for short) file system when you put a CD in the drive.

To make an ISO file system that holds the two mailbox files, open a terminal window and enter the following command:

$mkisofs -o mailbox.iso inbox.mbox inbox.idx

The -o mailbox.iso option tells mkisofs to write the resulting file system to a file named mailbox.iso. (You typically create the ISO image on your hard drive and then transfer it to a CD.)

Use the isovfy command to verify that the ISO file is in good shape: $ isovfy imagename.iso.

To write the ISO file to disc, use cdrecord just like we describe in the section, “Burning an ISO File to Disc at the Command Line,” earlier in this technique. For our example, we added the inbox ISO files to the command:

# cdrecord -eject dev=1,0,0 mailbox.iso

Of course, you have to use the device ID that you found in the section, “Finding the identity of your drive,” earlier in this technique.

If you haven’t tested your recorder’s burn performance, be sure to do a --dummy burn first to find the correct write speed. You can also find details on speed in “Running a test burn,” earlier in this technique.

You can also mount an ISO file system without first burning it to disc. When you mount an ISO image (using Linux’s loopback adapter), you’re sort of

treating the file system like an archive: It’s a collection of files and directories just like a tar archive. Any program can look inside a mounted file system and get to the files inside; you can’t do that with a tar archive.

To directly mount an ISO image, follow these steps:

1. Give yourself superuser privileges.

2. Create a mount point:

#mkdir /mnt/myiso

3.Mount the image to the mount point:

#mount -o loop ./mailbox.iso /mnt/myiso

4.Check out a listing of the ISO image with the ls command:

#ls /mnt/myiso

The mounted ISO image acts just like a drive. Look inside it and be sure it’s just right before you write it to disc.

Burning CDs without

Making an ISO First

If an ISO 9660 file system is so great, why would you ever want to burn a disc without one? To save time, of course (and disc space, too).

Sometimes, burning a raw data disc is the best way to save time and space. If you’re creating a backup CD or DVD, the archive tool that you’re using already builds a wrapper around all the files in the archive. Why wrap a file system around an archive when the archive already contains all the information that you need (filenames, permissions, owner IDs, and such)? Also, it takes time to create an ISO image. An ISO image takes up space on your hard drive until you’ve burned it to disc. If all you need is the data an ISO has to offer, then don’t waste time creating the ISO.

436 Technique 56: Burning CD-Rs without Getting Burned

You can pipe the output of a command directly into the standard input of cdrecord without creating an ISO image. For this to work, the recorder must support RAW-mode writing. Not all recorders support RAW mode. If you have a drive that doesn’t, you get an error message when you try to burn a CD.

To burn a CD (or DVD) with a backup of the /etc directory (the /etc directory is full of your config files — a good thing to back up), enter the following command:

#tar -czvf - /etc | cdrecord -eject dev=1,0,0 -

The -f - in the -czvf portion of the command tells tar to write the archive that it creates to its standard output stream. The | directs the output from the tar command to the cdrecord command. The - at the end of the cdrecord command tells cdrecord to read a data stream from its standard input (cdrecord burns whatever data you send to its standard input stream when you include a- at the end of the command line).

cdrecord doesn’t know how to split the data stream if the stream contains more data than the disc can hold. Use the cdbackup program that we cover in Technique 50 to split the stream across multiple discs.

You can’t mount a CD or DVD that’s been created this way because it doesn’t have a file system. Instead, you have to use a program that understands the raw data. To read a CD that you’ve created with raw tar data, use tar:

# tar -xzvf /dev/cdrom

This isn’t too difficult, and you’ve skipped all the intermediate disc image files, too.

Don’t forget that you can use the Nautilus browser with the burn:// protocol to make CDs. Check out Technique 1 for all the details!

57 Search and Destroy

setuid and setgid

Technique Programs

Save Time By

Understanding the true powers of a user’s identity

Using kfind to identify the setuid programs on your system

Carefully choosing which setuid bits to disable

There are valid reasons for having setuid and setgid programs on your system. Programs that allow other users to log in to your system are often setuid or setgid programs, and they have the power

to grant elevated privileges to otherwise unprivileged users.

Hackers are always looking for security loopholes that allow them to exploit even the slightest of vulnerabilities. Fortunately, popular programs like ssh are pretty tight, but other programs might not be so trustworthy. Security is ssh’s business — simple user applications that allow access to your system through a server might not be so careful to prevent program breakouts through a shell escape.

Keeping a vigilant eye on programs with setuid and setgid privileges is the quickest way to protect yourself from an intruder posing as an innocuous user. Closing the back door to hackers that would exploit that security lapse can save you a lot of time repairing damage to the system caused by an intruder. In this technique, we introduce you to setuid and setgid, and show you how to add another line of security to your system that will stop intruders in their tracks.

Exploring How setuid and setgid

Can Be Dangerous

Every user in a Linux system has a unique numeric user ID (called a UID). Every group has a unique numeric group ID (called a GID). If you log in twice (from two different workstations or from a remote computer), you still have the same UID. The UID is associated with the user, not with the login session.

438 Technique 57: Search and Destroy setuid and setgid Programs

Each time you run a program, Linux creates a new process for the program to run within. If you run two Solitaire games at the same time, you have two processes (but only one program). Each process has four attributes that determine what that process is allowed to do: a real UID, an effective UID (EUID), a real GID, and an effective GID (EGID).

When Linux creates a process on your behalf, the effective and real UIDs are set to your user ID. The effective and real GIDs are set to your primary group ID (you can belong to many groups, but at any one time, you have a single primary group ID).

The effective UID and effective GID are used to determine whether the process can access a given file. When you try to access a file, Linux classifies your effective user ID (and group) into one of three categories:

File Owner: If the effective user ID of the process matches the numeric UID of the file, you’re the file’s owner.

Group Member: If the effective GID of the process matches the numeric GID of the file, you’re a member of the file’s group.

Other: Your process is classified as an “other” if the effective UID doesn’t match and the effective GID doesn’t match.

After your identity has been classified, Linux checks the file permissions assigned to your category to be sure you have the privileges required to access that file.

When you run a program that has the setuid bit turned on, the effective user ID of the process is changed from your UID to the file’s UID. In other words, if you’re logged in as user freddie and you run a normal (non-setuid) program, the effective and real UID of the process is freddie. If freddie runs a

setuid program (owned by, say, user franklin), the effective UID of the process is changed from freddie to franklin (the real user ID remains freddie). Just by running a setuid program, freddie gains the privileges and permissions assigned to user franklin.

That isn’t a problem if franklin has limited privileges, but what if freddie runs a setuid program owned by root? The system would be at freddie’s mercy if he could start a terminal window from the program he’s running.

Anyone who runs a setuid program owned by root is automatically granted superuser privileges.

Remember, the superuser can

Kill off any process

Override file privileges

Grant program privileges

Lock users out

Change file ownerships

You can see from the list of privileges why you would want to limit the number of setuid and setgid programs on your system!

When you turn on the setuid and/or setgid bits for a program, the file’s owner and group IDs are very important. That’s because the privileges assigned to the owner (or group) are now assigned to anyone who runs the program. If you run a setuid program that’s owned by user root, you become the superuser while that program is running. Any processes spawned by the program run with superuser privileges, too. Imagine what would happen if you turned on the setuid bit for the bash shell (which is typically owned by user root) — anyone who ran the shell would suddenly become a superuser. Nasty business.