Welcome to the Bash Challenge #6 by Yes I Know IT & It’s FOSS. In this weekly challenge, we will show you a terminal screenshot, and ask you to explain why the result is not the one we were expecting.
Of course, the most amusing, and most creative, part of the challenge will be to find how to fix the command(s) displayed on the screen to obtain the correct result. Last week’s Bash Challenge was level one but we have up the ante this time and we have got a level 2 problem for you.
You can also buy these challenges (with unpublished challenges) in book form and support us:
Ready to play? So here is this week’s challenge:
The file that survived to rm
Today, our description is quite short: I have three files in a directory. As root, I used
rm * in that directory. But there is one file that obstinately refuses to be deleted:
root:011# ls -ls total 12 4 -rw-r--r-- 1 root root 29 nov 21 21:25 a 4 -rw-r--r-- 1 root root 29 nov 21 21:25 b 4 -rw-r--r-- 1 root root 29 nov 21 21:23 c root:012# rm * rm: cannot remove 'c': Operation not permitted root:013# ls -ls total 4 4 -rw-r--r-- 1 root root 29 nov 21 21:23 c
Your challenge is to find:
- What prevented the third file to be deleted?
- How to actually delete that file?
We’re looking forward to read your solutions in the comment section below!
To create this challenge, I used:
- GNU Bash, version 4.4.5 (x86_64-pc-linux-gnu)
- Debian 4.8.7-1 (amd64)
- All commands are those shipped with a standard Debian distribution
- No commands were aliased
How to reproduce
Here is the raw code we used to produce this challenge. If you run that in a terminal, you will be able to reproduce exactly the same result as displayed in the challenge illustration (assuming you are using the same software version as me) :
# as root : cd /tmp rm -rf ItsFOSS mkdir -p ItsFOSS cd ItsFOSS date > a date > b date > c sudo chattr +i c clear ls -ls rm * ls -ls
What was the problem ?
I used the
chattr command to set the (i)mmutable Linux filesystem attribute for the file
c. Depending your exact filesystem, all attribute changes are not available.
But here, I am using and ext2 filesystem that does support the
i flag. And to quote the man:
A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.
So basically after the
chattr +i the file is locked until we clear this flag. Please notice the attribute is stored in the filesystem. It will survive reboots & filesystem unmount/mount cycles.
How to fix that ?
First, we can check the explanation above by using the
lsattr command :
root:014# lsattr c ----i-------------- c
Clearly, the (i)mmutable flag is set. So, in order to remove that file (or to make any change to it), I have to clear that flag first. After that, I can do whatever I want on the file as usual :
root:015# chattr -i c root:016# lsattr c ------------------- c root:017# rm c root:018# ls -ls total 0
If you’re not aware of the existence of
chattr, its effects can be quite puzzling. Worth mentioning
chattr is a Linux-specific command, originally written for the ext2/3/4 filesystems. But today’s some of its feature are supported by other filesystems.
In the BSD-world, there is a similar command called
chflags. Read more on Wikipedia(https://en.
We hope you enjoyed that challenge. Stay tuned for more fun !