aboutsummaryrefslogtreecommitdiff
path: root/util-linux/switch_root.c
diff options
context:
space:
mode:
authorDenys Vlasenko <vda.linux@googlemail.com>2009-06-17 14:03:24 +0200
committerDenys Vlasenko <vda.linux@googlemail.com>2009-06-17 14:03:24 +0200
commita5bdbe10877e2e53aaba051eddfd5d47520657f5 (patch)
treece640a507e7afacb7c87adf103023a9cc1c696c4 /util-linux/switch_root.c
parentdc36a72ac0c1af3d973cd36849e6cac5cb7aa514 (diff)
downloadbusybox-w32-a5bdbe10877e2e53aaba051eddfd5d47520657f5.tar.gz
busybox-w32-a5bdbe10877e2e53aaba051eddfd5d47520657f5.tar.bz2
busybox-w32-a5bdbe10877e2e53aaba051eddfd5d47520657f5.zip
switch_root: allow /init to be a symlink; add doc (thanks Rob!)
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Diffstat (limited to 'util-linux/switch_root.c')
-rw-r--r--util-linux/switch_root.c97
1 files changed, 93 insertions, 4 deletions
diff --git a/util-linux/switch_root.c b/util-linux/switch_root.c
index b3b3bf7e6..0f00b605a 100644
--- a/util-linux/switch_root.c
+++ b/util-linux/switch_root.c
@@ -10,15 +10,15 @@
10 10
11// Make up for header deficiencies 11// Make up for header deficiencies
12#ifndef RAMFS_MAGIC 12#ifndef RAMFS_MAGIC
13#define RAMFS_MAGIC ((unsigned)0x858458f6) 13# define RAMFS_MAGIC ((unsigned)0x858458f6)
14#endif 14#endif
15 15
16#ifndef TMPFS_MAGIC 16#ifndef TMPFS_MAGIC
17#define TMPFS_MAGIC ((unsigned)0x01021994) 17# define TMPFS_MAGIC ((unsigned)0x01021994)
18#endif 18#endif
19 19
20#ifndef MS_MOVE 20#ifndef MS_MOVE
21#define MS_MOVE 8192 21# define MS_MOVE 8192
22#endif 22#endif
23 23
24// Recursively delete contents of rootfs 24// Recursively delete contents of rootfs
@@ -88,7 +88,7 @@ int switch_root_main(int argc UNUSED_PARAM, char **argv)
88 // we mean it. I could make this a CONFIG option, but I would get email 88 // we mean it. I could make this a CONFIG option, but I would get email
89 // from all the people who WILL destroy their filesystems. 89 // from all the people who WILL destroy their filesystems.
90 statfs("/", &stfs); // this never fails 90 statfs("/", &stfs); // this never fails
91 if (lstat("/init", &st) != 0 || !S_ISREG(st.st_mode) 91 if (stat("/init", &st) != 0 || !S_ISREG(st.st_mode)
92 || ((unsigned)stfs.f_type != RAMFS_MAGIC 92 || ((unsigned)stfs.f_type != RAMFS_MAGIC
93 && (unsigned)stfs.f_type != TMPFS_MAGIC) 93 && (unsigned)stfs.f_type != TMPFS_MAGIC)
94 ) { 94 ) {
@@ -119,3 +119,92 @@ int switch_root_main(int argc UNUSED_PARAM, char **argv)
119 execv(argv[0], argv); 119 execv(argv[0], argv);
120 bb_perror_msg_and_die("can't execute '%s'", argv[0]); 120 bb_perror_msg_and_die("can't execute '%s'", argv[0]);
121} 121}
122
123/*
124From: Rob Landley <rob@landley.net>
125Date: Tue, Jun 16, 2009 at 7:47 PM
126Subject: Re: switch_root...
127
128...
129...
130...
131
132If you're _not_ running out of init_ramfs (if for example you're using initrd
133instead), you probably shouldn't use switch_root because it's the wrong tool.
134
135Basically what the sucker does is something like the following shell script:
136
137 find / -xdev | xargs rm -rf
138 cd "$1"
139 shift
140 mount --move . /
141 exec chroot . "$@"
142
143There are a couple reasons that won't work as a shell script:
144
1451) If you delete the commands out of your $PATH, your shell scripts can't run
146more commands, but you can't start using dynamically linked _new_ commands
147until after you do the chroot because the path to the dynamic linker is wrong.
148So there's a step that needs to be sort of atomic but can't be as a shell
149script. (You can work around this with static linking or very carefully laid
150out paths and sequencing, but it's brittle, ugly, and non-obvious.)
151
1522) The "find | rm" bit will acually delete everything because the mount points
153still show up (even if their contents don't), and rm -rf will then happily zap
154that. So the first line is an oversimplification of what you need to do _not_
155to descend into other filesystems and delete their contents.
156
157The reason we do this is to free up memory, by the way. Since initramfs is a
158ramfs, deleting its contents frees up the memory it uses. (We leave it with
159one remaining dentry for the new mount point, but that's ok.)
160
161Note that you cannot ever umount rootfs, for approximately the same reason you
162can't kill PID 1. The kernel tracks mount points as a doubly linked list, and
163the pointer to the start/end of that list always points to an entry that's
164known to be there (rootfs), so it never has to worry about moving that pointer
165and it never has to worry about the list being empty. (Back around 2.6.13
166there _was_ a bug that let you umount rootfs, and the system locked hard the
167instant you did so endlessly looping to find the end of the mount list and
168never stopping. They fixed it.)
169
170Oh, and the reason we mount --move _and_ do the chroot is due to the way "/"
171works. Each process has two special symlinks, ".", and "/". Each of them
172points to the dentry of a directory, and give you a location paths can start
173from. (Historically ".." was also special, because you could enter a
174directory via a symlink so backing out to the directory you came from doesn't
175necessarily mean the one physically above where "." points to. These days I
176think it's just handed off to the filesystem.)
177
178Anyway, path resolution starts with "." or "/" (although the "./" at the start
179of the path may be implicit), meaning it's relative to one of those two
180directories. Your current directory, and your current root directory. The
181chdir() syscall changes where "." points to, and the chroot() syscall changes
182where "/" points to. (Again, both are per-process which is why chroot only
183affects your current process and its child processes.)
184
185Note that chroot() does _not_ change where "." points to, and back before they
186put crazy security checks into the kernel your current directory could be
187somewhere you could no longer access after the chroot. (The command line
188chroot does a cd as well, the chroot _syscall_ is what I'm talking about.)
189
190The reason mounting something new over / has no obvious effect is the same
191reason mounting something over your current directory has no obvious effect:
192the . and / links aren't recalculated after a mount, so they still point to
193the same dentry they did before, even if that dentry is no longer accessible
194by other means. Note that "cd ." is a NOP, and "chroot /" is a nop; both look
195up the cached dentry and set it right back. They don't re-parse any paths,
196because they're what all paths your process uses would be relative to.
197
198That's why the careful sequencing above: we cd into the new mount point before
199we do the mount --move. Moving the mount point would otherwise make it
200totally inaccessible to is because cd-ing to the old path wouldn't give it to
201us anymore, and cd "/" just gives us the cached dentry from when the process
202was created (in this case the old initramfs one). But the "." symlink gives
203us the dentry of the filesystem we just moved, so we can then "chroot ." to
204copy that dentry to "/" and get the new filesystem. If we _didn't_ save that
205dentry in "." we couldn't get it back after the mount --move.
206
207(Yes, this is all screwy and I had to email questions to Linus Torvalds to get
208it straight myself. I keep meaning to write up a "how mount actually works"
209document someday...)
210*/