Devices can be mounted to a path. For example "/dev/sda1" can be mounted to "/home/user". What I don't understand is how and where the " / " is mounted during boot.
Any help explaining?
Linux – How does the Linux or Unix “ / ” get mounted during bootup
filesystemslinuxmount
Related Solutions
The technology they're using to make this happen is called NFS - Network File System. They may additionally be using another technology with NFS called automounts, specifically Autofs if it's Linux.
NFS
NFS allows folders from one machine to be accessible to another. There is nothing magical about this. There is a client and server that is facilitating this connection. When you access one of these directories that's been mounted on your system via the NFS client, calls are made from your system to relay the information regarding the directory and it's contents.
If one of the clients accesses a file within the directory, the NFS server relays the contents of this file to the NFS client too.
Autofs
Automounting is a technology that allows a client system to access a shared remote resource, such as NFS, on a temporary basis. That is to say that the NFS client system has access to this remote NFS share. But it isn't actively "using" it until someone attempts to access the shared directory. Only then does the NFS client attempt to "mount" this remote directory and its contents.
File content life-cycle
In either case there is no implicit transfer of the files to the NFS clients. That is to say they aren't physically copied to the clients in any long term way. The files are streamed to the clients when they attempt to access them. After use they're gone; they do not persist at the clients in any long term form.
Just to give you a rough idea, you could use the program strace
to see some of the system calls that are made as a program runs. So, using this command for example:
$ strace echo "hello world" > afile
We could see how a file is written to the system. We could also use this form to write to an NFS mounted directory:
$ strace echo "hello world" > /home/sam/afile
Both of these traces a virtually identical.
### Local write
$ cat strace_wr_local.log
execve("/bin/echo", ["echo", "hello world"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f80000
write(1, "hello world\n", 12) = 12
close(1) = 0
### NFS write
$ cat strace_wr_remote.log
execve("/bin/echo", ["echo", "hello world"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fbe000
write(1, "hello world\n", 12) = 12
close(1) = 0
Reading is only slightly more interesting, but still basically identical.
### Local read
$ cat strace_rd_local.log
execve("/bin/cat", ["cat", "afile"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=1761, ...}) = 0
open("afile", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
read(3, "hello world\n", 4096) = 12
write(1, "hello world\n", 12hello world
) = 12
read(3, "", 4096) = 0
close(3) = 0
### NFS read
$ cat strace_rd_remote.log
execve("/bin/cat", ["cat", "/home/sam/afile"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=1771, ...}) = 0
open("/home/sam/afile", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
read(3, "hello world\n", 4096) = 12
write(1, "hello world\n", 12hello world
) = 12
read(3, "", 4096) = 0
close(3) = 0
Wading into the pool
If you're just generally curious about the NFS protocol you can read more about how it works here, in the section titled: NFS protocol basics. It's generally easy to get the basic concepts of how it works and there is an example of an NFS request, just to give you a general idea of how things work.
Diving deeper
If you truly want to peek behind the curtain you'll likely need to bring in a set of tools for collecting network traffic so that you can see the flowing of bits back and forth between the NFS server and one of its clients. Tools such has tcpdump
or wireshark
will likely be your friends in doing this deeper dive.
I would caution you to not waste your time unless you're truly the curious type, since deep dives like this require much skill and familiarity with a suite of Unix tools that I would consider only someone who has been using Unix for a dozen or so years.
This site will help you with this endeavor if you're truly curious:
Possibly relevant line earlier in the same document:
No setuid/setgid programs. Added support for filesystem capabilities to Android system files and removed all setuid/setguid programs. This reduces root attack surface and the likelihood of potential security vulnerabilities.
Regarding your final question:
If the system partition on Android devices is mounted with nosuid, then how can any of the system's core executables run as root, which they need to do in the earliest stages of startup?
nosuid
doesn't prevent root
from running processes. It is not the same as noexec
. It just prevents the suid
bit on executables from taking effect, which by definition means that a user cannot then run an application that would have permission to do things that the user doesn't have permission to do himself.
Also relevant here is an understanding of what "zygote" actually is; try reading https://android.stackexchange.com/a/77308
Disclaimer: I'm not an Android expert.
Best Answer
During the boot of a Unix system, the kernel does a few things that it doesn't do during normal operation. One of these things is to mount a filesystem on the directory
/
; this is quite different from normal mounting operations since the mounting is not triggered of amount
system call, and the target directory is not an existing directory. Another thing is to execute a program as PID 1, which is different from normal operation since this creates a process without duplicating an existing process.The way this “magic” mounting of the root directory is very different in different Unix variants. The kernel chooses what device to mount based on configuration parameters that may be specified in a variety of ways: compile-time configuration, runtime configuration in the kernel image, runtime configuration in some predefined memory location, command line parameters, … To find how it works on your machine, you would need to look at the documentation of your Unix variant, and find how your machine is configured.
To give an idea of how it works, here's an overview of how a modern Linux kernel operates. This is not the simplest example because Linux has a lot of history and varied use cases.
/
, which consists of files stored in RAM. This special filesystem is called initramfs; it's an instance of the rootfs filesystem type. The initramfs is populated by content either passed by the bootloader through an architecture-dependent protocol, compiled directly into the kernel image that is loaded into memory by the bootloader./
that is part of a restricted (but large) set of volume types that are recognized by the initialization code in the kernel. Such device types include any filesystem on common types of partitions on common types of disks (anything vaguely SCSI-like, including ATA, USB, etc.), as well as RAM disks and NFS mounts.