この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
CloudShellで実行するとまた違った面白い動作するらしい
こんにちは、OS破壊おじさんの のんピ(@non____97)です。
皆さんはOSを破壊したことはありますか? 以下記事の通り、私はあります。
そんな私にTwitterでとある方から「CloudShellで『rm -rf /*』をやると、また違った面白い動作をする」と情報をいただきました。
CloudShellはシェルプロンプトの環境でありOSではないですが、これは試さずにはいられません。
いきなりまとめ
rm -rf /*
を実行すると、やっぱり/bin
などディレクトリが削除され、ビルトインコマンド以外のコマンドは実行できなくなる- CloudShellを再起動すれば環境が再作成され、再度CloudShell上でコマンドを実行することは可能
- しかし、ホームディレクトリ
$HOME
は再起動しても元に戻らないので要注意
早速試してみた
普段使っているリージョンで試すと何かあった時に業務に影響が出るので、フランクフルトリージョン(eu-central-1
)のCloudShellで検証してみます。
マネージメントコンソールからCloudShellのセッションを開始します。セッションを開始するとCreating the environment...
となっていますが、すぐにお別れすることになります。儚いものですね。
また、複数のタブでCloudShellを開いていれば壊れゆく様を確認できるかと思ったので、別ウィンドウでもフランクフルトリージョンでCloudShellを起動しておきます。
それでは、お別れする前にCloudShellの実行環境のOSのバージョンやディレクトリ構成などを確認しておきます。
# rootユーザーへの昇格
$ sudo -i
# 現在のユーザーの確認
$ whoami
root
# ディストリビューションの確認
$ cat /etc/system-release
Amazon Linux release 2 (Karoo)
$ cat /etc/os-release
NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"
# /root ディレクトリ配下の確認
$ ls -la /
total 7088
drwxr-xr-x 1 root root 4096 Dec 17 04:30 .
drwxr-xr-x 1 root root 4096 Dec 17 04:30 ..
drwxr-xr-x 3 root root 4096 Dec 17 04:30 aws
lrwxrwxrwx 1 root root 7 Oct 1 01:14 bin -> usr/bin
dr-xr-xr-x 2 root root 4096 Apr 9 2019 boot
drwxr-xr-x 5 root root 340 Dec 17 04:30 dev
drwxr-xr-x 1 root root 4096 Dec 17 04:30 etc
drwxr-xr-x 4 root root 4096 Dec 17 04:30 home
lrwxrwxrwx 1 root root 7 Oct 1 01:14 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Oct 1 01:14 lib64 -> usr/lib64
-rw-r--r-- 1 root root 7178320 Oct 5 10:58 libicu-50.2-4.amzn2.x86_64.rpm
drwxr-xr-x 2 root root 4096 Oct 1 01:14 local
drwxr-xr-x 2 root root 4096 Apr 9 2019 media
drwxr-xr-x 2 root root 4096 Apr 9 2019 mnt
drwxr-xr-x 1 root root 4096 Oct 5 11:01 opt
dr-xr-xr-x 131 root root 0 Dec 17 04:30 proc
dr-xr-x--- 1 root root 4096 Oct 5 11:01 root
drwxr-xr-x 1 root root 4096 Dec 17 04:30 run
lrwxrwxrwx 1 root root 8 Oct 1 01:14 sbin -> usr/sbin
drwxr-xr-x 2 root root 4096 Apr 9 2019 srv
dr-xr-xr-x 13 root root 0 Dec 17 04:31 sys
drwxrwxrwt 1 root root 4096 Dec 17 04:30 tmp
drwxr-xr-x 1 root root 4096 Oct 1 01:14 usr
drwxr-xr-x 1 root root 4096 Oct 1 01:14 var
# /var/log ディレクトリ配下の確認
$ ls -l /var/log/
total 296
-rw------- 1 root utmp 0 Oct 5 11:00 btmp
-rw-r--r-- 1 root root 292292 Dec 17 04:47 lastlog
-rw------- 1 root root 0 Oct 5 11:00 tallylog
-rw-rw-r-- 1 root utmp 0 Oct 5 11:00 wtmp
-rw------- 1 root root 7325 Dec 17 04:30 yum.log
# マウントしているディスクの空き領域の確認
$ df -h
Filesystem Size Used Avail Use% Mounted on
overlay 30G 9.3G 19G 34% /
tmpfs 64M 0 64M 0% /dev
shm 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/xvdcz 30G 9.3G 19G 34% /aws/mde
/dev/loop0 976M 2.6M 907M 1% /home
tmpfs 3.9G 0 3.9G 0% /proc/acpi
tmpfs 3.9G 0 3.9G 0% /sys/firmware
tmpfs 3.9G 0 3.9G 0% /proc/scsi
# マウントしているディスクの情報確認
$ mount
overlay on / type overlay (rw,relatime,lowerdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/211/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/184/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/183/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/182/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/181/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/180/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/179/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/131/fs,upperdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/222/fs,workdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/222/work)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (ro,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory,release_agent=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/220/fs/tmp/snappy_escape/fd9e51ef-80e1-4e7e-af81-b54cc4c4b3fc/cmd)
/dev/xvdcz on /aws/mde type ext4 (rw,relatime,data=ordered)
/mnt/task/volumes/0d3343351dd84ef49348e221b3266566/volumes/mde-private-volume/home.data on /home type ext4 (rw,relatime,data=ordered)
/dev/xvdcz on /etc/hosts type ext4 (rw,relatime,data=ordered)
/dev/xvdcz on /etc/resolv.conf type ext4 (rw,relatime,data=ordered)
/dev/xvdcz on /etc/hostname type ext4 (rw,relatime,data=ordered)
proc on /proc/bus type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/fs type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/irq type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/sys type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/sysrq-trigger type proc (ro,nosuid,nodev,noexec,relatime)
tmpfs on /proc/acpi type tmpfs (ro,relatime)
tmpfs on /proc/kcore type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/latency_stats type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/timer_list type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/sched_debug type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /sys/firmware type tmpfs (ro,relatime)
tmpfs on /proc/scsi type tmpfs (ro,relatime)
/var/log/messages
があれば、tail -f
で眺めてみたかったのですが、どうやら無いようですね。
なんとなくrm -rf /
も実行してみました。こちらはやはり–no-preserve-root
オプションを付けなければ、削除処理が実行されない安全仕様になっています。
$ rm -rf /
rm: it is dangerous to operate recursively on ‘/’
rm: use --no-preserve-root to override this failsafe
もう思い起こすことはないので、rm -rf /*
を実行してあげます。
# /root ディレクトリに移動
$ cd /
# 現在のディレクトリの確認
$ pwd
/
$ rm -rf /*
.
.
.
rm: cannot remove ‘/sys/module/jbd2/sections/.exit.text’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.bss’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/_ftrace_events’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.orc_unwind_ip’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.gnu.linkonce.this_module’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.symtab’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.rodata’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.init.text’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.note.gnu.build-id’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.text’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.data’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.smp_locks’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/__bug_table’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.rodata.str1.1’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.parainstructions’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.text.unlikely’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/__ksymtab_strings’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.rodata.str1.8’: Read-only file system
rm: cannot remove ‘/sys/module/jbd2/sections/.ref.data’: Read-only file system
-bash-4.2#
1分程度でコマンドの実行は完了しました。Amazon Linux 2で実行した時は20分ほどかかったので、あまり手応えがありません。
しかし、流石はrm -rf /*
です。ls
やwhich
を叩いてもcommand not found
と片付けられてしまいました。なお、cd
はビルトインコマンドであるため、rm -rf /*
の影響を受けず、実行できています。ちなみに、もう片方のセッションでも試してみましたが、同様のエラーが出力されました。
# ls -l
-bash: ls: command not found
# cd
-bash: cd: /root: No such file or directory
# which
-bash: /usr/bin/which: No such file or directory
CloudShellにマウントしてあるディスクをEC2インスタンスにアタッチするなどは現時点ではできないので、具体的にどこまで削除されたかをこれ以上は確認できませんでした。
取り敢えず満足したので、できれば元に戻してあげたいと思います。
試しに、セッションを一旦閉じてから再度開き直しました。すると、以下のようにとても興奮するメッセージが出力されました。
Preparing your terminal...
/root/exec-client.sh: line 2: /aws/mde/exec-vars.sh: No such file or directory
flag needs an argument: -unix
Usage of /usr/bin/controller:
-accountId string
environment owner account ID
-branch string
the branch of the repository to clone to. @optional
-cloneDir string
the directory where cloning should be performed
-controlPlaneApiGwEndpointDns string
Endpoint DNS for control plane API
-controlPlaneApiGwId string
control plane API Gateway ID
-credPort int
the port on which to run the credential server (default 1338)
-credentialsS3ObjectArn string
the S3 object ARN that contains credentials
-credentialsUpdaterEnabled
enable credentials updater (default true)
-enableControlPlaneApiFeature
enable getting credentials from control plane API
-enableHightideLoggingFeature
enable logs publishing to hightide s3 buckets
-environmentId string
environment ID
-gitCredSrvPort int
the port on which to run the git cTry these commands to get started:
aws help or aws <command> help or aws <command> --cli-auto-prompt
redential server (default 1340)
-hightideLogDir string
provide the log directory of hightide worker (default "/store/projects/.c9/worker/logs")
-mode string
the functionality to use; one of "credentials", "ssm-agent", "client", "server", "hightide-logging-daemon" (default "credentials")
-sourceURI string
the repository URI to clone
-taskArn string
the ECS task arn
-taskIdS3ObjectArn string
the S3 object ARN that contains the task ID
-unix string
the path where the exec unix socket is located (default "/aws/mde/mde.sock")
Lost your connection to the environment.
Press any key to reconnect and continue using AWS CloudShell
Connection is lost. Please refresh the browser to re-establish the connection.
どうやら、セッションを繋ぎ直しても、環境を用意するためのコマンドが実行できないようですね。
Press any key to reconnect and continue using AWS CloudShell
と出力されたので、何かキーを押しても同じメッセージが繰り返し表示されるだけでした。
巷では「困った時には再起動」と金言があるので、次にCloudShellの再起動をしてみます。
Actions
- Restart AWS CloudShell
をクリックします。
「再起動すると現在のリージョンでアクティブなセッションが全て停止するぞ」と警告されます。もう片方のセッションも何もできない状況なので、Restart
をクリックします。
すると、以下のようにStopping the environment...
となりました。
CloudShellを再起動した影響で、警告された通り、もう片方のセッションは停止されていました。
そのまましばらく待つと、Waiting for the environment to run...
となり、最終的に正常にCloudShellが起動しました。
ls -la
やdf -h
を実行した結果、どうやら元気そうですね。めでたしめでたし。
$ ls -la /
total 7088
drwxr-xr-x 1 root root 4096 Dec 17 05:09 .
drwxr-xr-x 1 root root 4096 Dec 17 05:09 ..
drwxr-xr-x 3 root root 4096 Dec 17 05:09 aws
lrwxrwxrwx 1 root root 7 Oct 1 01:14 bin -> usr/bin
dr-xr-xr-x 2 root root 4096 Apr 9 2019 boot
drwxr-xr-x 5 root root 340 Dec 17 05:09 dev
drwxr-xr-x 1 root root 4096 Dec 17 05:10 etc
drwxr-xr-x 3 root root 4096 Dec 17 05:09 home
lrwxrwxrwx 1 root root 7 Oct 1 01:14 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Oct 1 01:14 lib64 -> usr/lib64
-rw-r--r-- 1 root root 7178320 Oct 5 10:58 libicu-50.2-4.amzn2.x86_64.rpm
drwxr-xr-x 2 root root 4096 Oct 1 01:14 local
drwxr-xr-x 2 root root 4096 Apr 9 2019 media
drwxr-xr-x 2 root root 4096 Apr 9 2019 mnt
drwxr-xr-x 1 root root 4096 Oct 5 11:01 opt
dr-xr-xr-x 113 root root 0 Dec 17 05:09 proc
dr-xr-x--- 1 root root 4096 Oct 5 11:01 root
drwxr-xr-x 1 root root 4096 Dec 17 05:10 run
lrwxrwxrwx 1 root root 8 Oct 1 01:14 sbin -> usr/sbin
drwxr-xr-x 2 root root 4096 Apr 9 2019 srv
dr-xr-xr-x 13 root root 0 Dec 17 05:09 sys
drwxrwxrwt 1 root root 4096 Dec 17 05:10 tmp
drwxr-xr-x 1 root root 4096 Oct 1 01:14 usr
drwxr-xr-x 1 root root 4096 Oct 1 01:14 var
$ df -h
Filesystem Size Used Avail Use% Mounted on
overlay 30G 9.2G 19G 33% /
tmpfs 64M 0 64M 0% /dev
shm 3.8G 0 3.8G 0% /dev/shm
tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
/dev/nvme1n1 30G 9.2G 19G 33% /aws/mde
/dev/loop0 976M 174M 736M 20% /home
tmpfs 3.8G 0 3.8G 0% /proc/acpi
tmpfs 3.8G 0 3.8G 0% /sys/firmware
なお、再起動前後でターミナル上に表示されているIPアドレスが10-0-110-112
から10-0-178-16
に変化しています。起動するタイミングでVDIのように、CloudShellの実行環境となる専用のVMごと作り直す動作をしていそうですね。
おまけ1. /binと/usr以外のディレクトリを削除してみた
/bin
が削除されてしまうと確認用のコマンドも打てないので、番外編として/bin
と/usr
以外のディレクトリを削除してみます。(/usr/bin
ではなく、/usr
なのはご愛嬌)
早速以下コマンドを実行してみます。
# rootユーザーへの昇格
$ sudo -i
# 現在のユーザーの確認
$ whoami
root
# /root ディレクトリに移動
$ cd /
# 現在のディレクトリの確認
$ pwd
/
# /bin と /usr が含まれていないことを確認
$ ls | grep -v -E "usr|bin"
aws
boot
dev
etc
home
lib
lib64
libicu-50.2-4.amzn2.x86_64.rpm
local
media
mnt
opt
proc
root
run
srv
sys
tmp
var
# /bin と /usr 以外のディレクトリを削除
$ ls | grep -v -E "usr|bin" | xargs rm -rf
.
.
.
rm: cannot remove ‘sys/module/jbd2/sections/__jump_table’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.data..read_mostly’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.strtab’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/__tracepoints_ptrs’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/__mcount_loc’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.exit.text’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.bss’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/_ftrace_events’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.orc_unwind_ip’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.gnu.linkonce.this_module’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.symtab’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.rodata’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.init.text’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.note.gnu.build-id’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.text’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.data’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.smp_locks’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/__bug_table’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.rodata.str1.1’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.parainstructions’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.text.unlikely’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/__ksymtab_strings’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.rodata.str1.8’: Read-only file system
rm: cannot remove ‘sys/module/jbd2/sections/.ref.data’: Read-only file system
ls | grep -v -E "usr|bin" | xargs rm -rf
は30秒ほどで完了しました。
それでは、ls
やdir
などコマンドを実行できるか確認してみます。
$ ls -l
-bash: /bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
$ dir
-bash: /bin/dir: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
残念ながらいずれのコマンドもシステムライブラリである/lib64/ld-linux-x86-64.so.2
がないため、実行できませんでした。残念。
試しにセッションを一度閉じて再度接続してみましたが、こちらはrm -rf /*
と同じメッセージが出力されました。
Preparing your terminal...
/root/exec-client.sh: line 2: /aws/mde/exec-vars.sh: No such file or directory
flag needs an argument: -unix
Usage of /usr/bin/controller:
-accountId string
environment owner account ID
-branch string
the branch of the repository to clone to. @optional
-cloneDir string
the directory where cloning should be performed
-controlPlaneApiGwEndpointDns string
Endpoint DNS for control plane API
-controlPlaneApiGwId string
control plane API Gateway ID
-credPort int
the port on which to run the credential server (default 1338)
-credentialsS3ObjectArn string
the S3 object ARN that contains credentials
-credentialsUpdaterEnabled
enable credentials updater (default true)
-enableControlPlaneApiFeature
enable getting credentials from control plane API
-enableHightideLoggingFeature
enable logs publishing to hightide s3 buckets
-environmentId string
environment ID
-gitCredSrvPort int
the port on which to run the git cTry these commands to get started:
aws help or aws <command> help or aws <command> --cli-auto-prompt
redential server (default 1340)
-hightideLogDir string
provide the log directory of hightide worker (default "/store/projects/.c9/worker/logs")
-mode string
the functionality to use; one of "credentials", "ssm-agent", "client", "server", "hightide-logging-daemon" (default "credentials")
-sourceURI string
the repository URI to clone
-taskArn string
the ECS task arn
-taskIdS3ObjectArn string
the S3 object ARN that contains the task ID
-unix string
the path where the exec unix socket is located (default "/aws/mde/mde.sock")
Lost your connection to the environment.
Press any key to reconnect and continue using AWS CloudShell
Connection is lost. Please refresh the browser to re-establish the connection.
しょうがないので、伝家の宝刀CloudShell再起動を試してみます。再起動後は以下のように正常にコマンドを実行できました。流石です。
$ ls -l /
total 7080
drwxr-xr-x 3 root root 4096 Dec 18 07:57 aws
lrwxrwxrwx 1 root root 7 Oct 1 01:14 bin -> usr/bin
dr-xr-xr-x 2 root root 4096 Apr 9 2019 boot
drwxr-xr-x 5 root root 340 Dec 18 07:57 dev
drwxr-xr-x 1 root root 4096 Dec 18 07:57 etc
drwxr-xr-x 3 root root 4096 Dec 18 07:57 home
lrwxrwxrwx 1 root root 7 Oct 1 01:14 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Oct 1 01:14 lib64 -> usr/lib64
-rw-r--r-- 1 root root 7178320 Oct 5 10:58 libicu-50.2-4.amzn2.x86_64.rpm
drwxr-xr-x 2 root root 4096 Oct 1 01:14 local
drwxr-xr-x 2 root root 4096 Apr 9 2019 media
drwxr-xr-x 2 root root 4096 Apr 9 2019 mnt
drwxr-xr-x 1 root root 4096 Oct 5 11:01 opt
dr-xr-xr-x 110 root root 0 Dec 18 07:57 proc
dr-xr-x--- 1 root root 4096 Oct 5 11:01 root
drwxr-xr-x 1 root root 4096 Dec 18 07:57 run
lrwxrwxrwx 1 root root 8 Oct 1 01:14 sbin -> usr/sbin
drwxr-xr-x 2 root root 4096 Apr 9 2019 srv
dr-xr-xr-x 13 root root 0 Dec 18 07:57 sys
drwxrwxrwt 1 root root 4096 Dec 18 07:57 tmp
drwxr-xr-x 1 root root 4096 Oct 1 01:14 usr
drwxr-xr-x 1 root root 4096 Oct 1 01:14 var
$ ls -l /lib64/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 10 Oct 1 01:14 /lib64/ld-linux-x86-64.so.2 -> ld-2.26.so
おまけ2. chmod -R 000 / を実行してみた
なんだか消化不良なので、もはやrm -rf /*
の派生系でも何でもないですが、chmod -R 000 /
を実行して/root
配下の権限を全て奪ってみます。
早速以下コマンドを実行してみます。
# rootユーザーへの昇格
$ sudo -i
# 現在のユーザーの確認
$ whoami
root
# /root ディレクトリに移動
$ cd /
# 現在のディレクトリの確認
$ pwd
/
# /root 配下の全てのディレクトリとファイルの読み取り、書き込み、実行権限を無効化
$ chmod -R 000 /
.
.
.
chmod: changing permissions of ‘/sys/module/jbd2/sections/_ftrace_events’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.orc_unwind_ip’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.gnu.linkonce.this_module’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.symtab’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.rodata’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.init.text’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.note.gnu.build-id’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.text’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.data’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.smp_locks’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/__bug_table’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.rodata.str1.1’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.parainstructions’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.text.unlikely’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/__ksymtab_strings’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.rodata.str1.8’: Read-only file system
chmod: changing permissions of ‘/sys/module/jbd2/sections/.ref.data’: Read-only file system
rm -rf /*
と同様にエラーを吐きながらも終了しました。
続いて各種コマンドを実行したところ、いずれもPermission denied
と表示されて、何もできない状態になりました。ただ例外として、exit
のみ正常です。私が望んでいたのはこれです。これ。
$ ls -l /
-bash: /bin/ls: Permission denied
$ dir
-bash: /bin/dir: Permission denied
$ whoami
-bash: /bin/whoami: Permission denied
$ exit
logout
セッションを一度閉じて再度接続した場合もrm -rf /*
と異なるメッセージが表示されました。テンション上がってきました。
Preparing your terminal...
Failed to open session : Timed out while opening the session
Trying to open session (Retrying. Attempt #1)
Connection is lost. Please refresh the browser to re-establish the connection.
Failed to open session : Timed out while opening the session
Trying to open session (Retrying. Attempt #2)
Connection is lost. Please refresh the browser to re-establish the connection.
Failed to open session : Timed out while opening the session
Trying to open session (Retrying. Attempt #3)
Connection is lost. Please refresh the browser to re-establish the connection.
Failed to open session : Timed out while opening the session
Trying to open session (Retrying. Attempt #4)
Connection is lost. Please refresh the browser to re-establish the connection.
Failed to open session : Timed out while opening the session
Trying to open session (Retrying. Attempt #5)
Connection is lost. Please refresh the browser to re-establish the connection.
最後に伝家の宝刀CloudShell再起動を試してみます。コマンドは正常に実行できたのですが、再接続すると通常はホームディレクトリ(/home/cloudshell-user/
)がカレントディレクトリのところ、/root
がカレントディレクトリとなっていました。/home
の権限を確認してみると、全ての権限がない状態になっていました。
$ pwd
/
$ ls -ld /home
d--------- 3 root root 4096 Dec 18 07:57 /home
元々の権限は755
だったので、対応としてchmod 755 -R /home
で権限を戻してあげます。
# rootユーザーへの昇格
$ sudo -i
$ chmod 755 -R /home
$ ls -ld /home/
drwxr-xr-x 3 root root 4096 Dec 18 07:57 /home/
$ ls -l /home/
total 4
drwxr-xr-x 3 cloudshell-user cloudshell-user 4096 Dec 18 08:14 cloudshell-user
$ ls -l /home/cloudshell-user/
total 0
意図した権限に変わったことを確認した後、CloudShellを再起動してカレントディレクトリを確認しところ、正常にホームディレクトリ(/home/cloudshell-user/
)がカレントディレクトリとなっていました。
$ pwd
/home/cloudshell-user
再起動で復元はするけどホームディレクトリは元に戻らないので要注意
AWS CloudShellで「rm -rf /*」を実行してみました。
再起動で実行環境は確かに復元はしますが、当然ながらホームディレクトリ($HOME
)は元に戻らないので要注意です。「自分も試しみたい!!」という方がいれば必ず何も保存していない、業務に影響のない環境で試してください。(それでも事故の元なので推奨はしません。)
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!