ちょっと話題の記事

AWS CloudShellで「rm -rf /*」を実行してみた

よい子(大人を含む)はマネしないでね。CloudShellを再起動すればホームディレクトリ以外の領域は元に戻るのでちょっと安心。
2021.12.17

この記事は公開されてから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を起動しておきます。

複数ウィンドウでの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 /*です。lswhichを叩いても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 AWS CloudShell

「再起動すると現在のリージョンでアクティブなセッションが全て停止するぞ」と警告されます。もう片方のセッションも何もできない状況なので、Restartをクリックします。

CloudShellの再起動の警告

すると、以下のようにStopping the environment...となりました。

Stopping the environment

CloudShellを再起動した影響で、警告された通り、もう片方のセッションは停止されていました。

You session has ended

そのまましばらく待つと、Waiting for the environment to run...となり、最終的に正常にCloudShellが起動しました。

Waiting for the environment to run

CloudShell再起動確認

ls -ladf -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秒ほどで完了しました。

それでは、lsdirなどコマンドを実行できるか確認してみます。

$ 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)でした!