Page 213
The ATAPI standard arrived in time to ensure that all non-SCSI CD-ROM drives at quad speed or faster use a standard interface, so the situation is far simpler for new CD-ROM drives. Support for ATAPI CD-ROMs is taken care of by one driver for all drives. The ATAPI standard also provides for very large hard disk drives and tape drives. ATAPI CD-ROM drives are attached to IDE interfaces, just like hard disks, and they have the same set of device names as hard disk devices.
Because CD-ROMs come already written, there is no need to partition them. They are accessed using the device names for whole-disk devices: /dev/hda, /dev/hdb, and so on.
The ISO 9660 standard specifies a standard format for the layout of data on CD-ROMs. It restricts filenames to no more than 32 characters, for example. Most CD-ROMs are written with very short filenames, for compatibility with MS-DOS. To support certain UNIX features such as symbolic links and long filenames, a set of extensions called Rock Ridge was developed, and the Linux kernel will automatically detect and make use of the Rock Ridge extensions.
CD-ROM drives also usually support the playing of audio CDs, and there are many Linux programs for controlling the CD-ROM drive, in just the same way as one might control a CD player. The multimedia package on the Red Hat 4.2 CD-ROM contains the xplaycd program, which can be used for playing CDs. To make it work, you need to set the /dev/cdrom symbolic link to point to your real CD-ROM device.
Loopback devices enable new filesystems to be stored inside regular files. You might want to do this to prepare an emulated hard disk image for DOSEMU, an install disk, or just to try out a filesystem of a new type or an ISO9660 CD-ROM image before writing it to the CD writer.
Under UNIX, root permissions are needed to change the system's filesystem structure; even if you own a file and the mount point on which you want to mount it, only root can do this, unless the user option has been specified in /etc/fstab for this filesystem.
When a filesystem is mounted using the loopback driver, the file containing the filesystem plays the role of the block device in the mount command and /etc/fstab. The kernel talks to the block device interface provided by the loopback device driver, and the driver forwards operations to the file:
# mount $(pwd)/rtems.iso -t iso9660 -o ro,loop /mnt/test # ls -F /mnt/test INSTALL LICENSE README SUPPORT c/ doc/ rr_moved/ # mount | grep loop | fold -s /home/james/documents/books/Sams/Linux-Unleashed-2/ch9/tmp/rtems.iso on /mnt/test type iso9660 (ro,loop=/dev/loop0) # umount /mnt/test
Once the loopback filesystem is mounted, it's just a normal filesystem.
Page 214
Loopback filesystems offer even more—encryption, for example. A loopback filesystem can be configured to decrypt data from the block device on-the-fly so that the data on the device is useless to people even if they can read it—unless they have the password. The mount command prompts for the password at the appropriate time. To make this work, first you have to use mkfs to generate a filesystem on the encrypted block device; losetup is used to associate a loop device and encryption method with the block device you want to use (in the following case, a floppy drive):
# /sbin/losetup -e DES /dev/loop0 /dev/fd1 Password: Init (up to 16 hex digits): # /sbin/mkfs -t ext2 -m0 /dev/loop0 mke2fs 1.10, 24-Apr-97 for EXT2 FS 0.5b, 95/08/09 Linux ext2 filesystem format Filesystem label= 360 inodes, 1440 blocks 0 blocks (0.00) reserved for the super user First data block=1 Block size=1024 (log=0) Fragment size=1024 (log=0) 1 block group 8192 blocks per group, 8192 fragments per group 360 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done # losetup -d /dev/loop0
As shown previously, the losetup's -e option associates an encryption method and block device with a loopback device. The -d option deletes this association and erases the stored encryption key.
When the filesystem has been created on the encrypted device, it can be mounted in a manner similar to the normal case:
# /sbin/losetup -d /dev/loop0 # mount /dev/fd1 -t ext2 -o loop=/dev/loop0,encryption=DES /mnt/test Password: Init (up to 16 hex digits): # ls /mnt/test lost+found
Usually, the whole process of using an encrypted filesystem can be set up for ordinary users by adding the appropriate line to /etc/fstab:
$ mount /mnt/test Password: Init (up to 16 hex digits): $ ls -ld /mnt/test drwxrwxrwx 3 james root 1024 Sep 14 22:04 /mnt/test
In this example, root has enabled users to mount encrypted filesystems by including
/dev/fd1 /mnt/test ext2 user,loop,encryption=DES
Page 215
in /etc/fstab. Additionally, ownership of the top-level directory on the floppy disk has been given to the user james because presumably it is his floppy disk. If root had not done this, james would have been able to mount his filesystem but not read it. It was essential to do that, but it turns out that in this example, root has made a fatal mistake. As well as changing the ownership of the filesystem's root directory, root has changed the directory's mode as well. This means that once the unsuspecting james has supplied his very secret password, any user on the system can read and write the files on the floppy! This underlines the fact that encryption alone is not sufficient for safety. Careful thought is also essential.
In the previous case, the file ownerships and permissions have turned out to me more of a hindrance than a help. It would probably be better to use an MS-DOS filesystem on the encrypted device, because ownership is automatically given away to the user mounting the disk and the file modes are set correctly:
$ ls -ld /mnt/floppy/ drwxr-xr-x 2 james users 7168 Jan 1 1970 /mnt/floppy/
However there are still two problems with this strategy. First, it is not possible to make an encrypted filesystem easily on a floppy, because the mkfs.msdos program needs to know the geometry for the device on which it is creating the filesystem and the loopback device drivers don't really have geometries. Second, once your encrypted ext2 filesystem is mounted, the superuser can still read your data.
The encryption methods outlined previously are not available in standard kernels because most useful forms of encryption technology are not legally exportable from the United States. However, they are already available outside the United States at the URL ftp://ftp.replay.com/pub/linux/all/linux-crypt-kernelpatches.tar.gz
This site is in Holland. You need to apply these patches to your kernel and recompile it in order to use the DES and IDEA encryption methods with loopback devices. The patches were made against version 2.0.11 of the Linux kernel, but they work perfectly well with the kernel supplied with Red Hat Linux 4.2.
To summarize, encrypted filesystems can be useful for some kinds of data (for example, for storing digital signatures for important system binaries in such a way that they can't be tampered with), but their usefulness to users other than root is limited. However, of course all the ordinary file encryption mechanisms are still available to and useful for ordinary users.
Although hard disks, floppy disks, and CD-ROM drives are probably the most heavily used block devices, there are other kinds of block devices too. These include ramdisks and Zip drives.
Ramdisks are block devices that store their data in RAM rather than on a disk. This means they are very fast; nevertheless, ramdisks are rarely used with Linux because Linux has a very good