Linux Kernel Architecture

(Jacob Rumans) #1

Chapter 2: Process Management and Scheduling


fs/exec.c
int prepare_binprm(struct linux_binprm *bprm)
{
...
bprm->e_uid = current->euid;
bprm->e_gid = current->egid;

if(!(bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID)) {
/* Set-uid? */
if (mode & S_ISUID) {
bprm->e_uid = inode->i_uid;
}

/* Set-gid? */
/*
* If setgid is set but no group execute bit then this
* is a candidate for mandatory locking, not a setgid
* executable.
*/
if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
bprm->e_gid = inode->i_gid;
}
}
...
}

After making sure thatMNT_NOSUIDisnotset for the mount from which the file originates, the kernel
checks if the SUID or SGID bit is set. The first case is simple to handle: IfS_ISUIDis set, then the effective
UID gets the same value as the inode (otherwise, the process’s effective UID is used). The SGID case is
similar, but the kernel must additionally make sure that the execute bit is also set for the group.


Linux supports various organization formats for executable files. The standard format is ELF (Executable
and Linkable Format), which I discuss at length in Appendix E. Other alternatives are the variants shown
in Table 2-2 (which lists the names of the correspondinglinux_binfmtinstances in the kernel).


Even though many binary formats can be used on different architectures (ELF was designed explicitly to
be as system-independent as possible), this does not mean that programs in a specific binary format are
able to run on multiple architectures. The assembler statements used still differ greatly from processor to
processor and the binary format only indicates how the different parts of a program — data, code, and
so on — are organized in the executable file and in memory.


search_binary_handleris used at the end ofdo_execveto find a suitable binary format for the particular
file. Searching is possible because each format can be recognized by reference to special characteristics
(usually a ‘‘magic number‘‘ at the beginning of the file). The binary format handler is responsible for
loading the data of the new program into the old address space. Appendix E describes the steps needed
to do this when the ELF format is used. Generally, a binary format handler performs the following
actions:


❑ It releases all resources used by the old process.
❑ It maps the application into virtual address space. The following segments must be taken into
account (the variables specified are elements of the task structure and are set to the correct values
by the binary format handler):
Free download pdf