Scenario / Questions
I have a very important file which an application in my workplace uses, i need to make sure it is not delete whatsoever, how can I do that?
Find below all possible solutions or suggestions for the above questions..
Yes, you can change the attributes of the file to read-only.
The command is:
chattr +i filename
And to disable it:
chattr -i filename
A file with the
iattribute 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_IMMUTABLEcapability can set or clear this attribute.
Burn it to a CD. Put the CD in a CD-ROM drive and access it from there.
- Create a file system image.
- Mount the image.
- Copy the file to the mounted image.
- Unmount the image and remount it as read-only.
- Now you can’t delete it.
# dd if=/dev/zero of=readonly.img bs=1024 count=1024 # mkfs.ext2 readonly.img # mkdir readonlyfolder # mount readonly.img readonlyfolder/ # echo "can't delete this" > readonlyfolder/permanent.txt # umount readonlyfolder # mount -o ro readonly.img readonlyfolder # cat readonlyfolder/permanent.txt can't delete this # rm readonlyfolder/permanent.txt rm: cannot remove `readonlyfolder/permanent.txt': Read-only file system
You should create multiple hard links to the file as well. These should be in various locations that regular users can’t access.
This way, even if they do manage to override your chattr protection, the data will remain and you can easily restore it where your application is looking for it.
Linux has so-called bind-mount option which is rather powerful and useful feature to know:
% cd $TMP && mkdir usebindmountluke && cd usebindmountluke % echo usebindmountluke > preciousfile % sudo mount -B preciousfile preciousfile % sudo mount -oremount,ro preciousfile % echo sowhat > preciousfile zsh: read-only file system: preciousfile % rm preciousfile rm: cannot remove ‘preciousfile’: Read-only file system
— what’s being done here is bind-mount file to itself (yes, you can do that in Linux), then it’s re-mounted in R/O-mode. Of course this can be done to directory as well.
Others have answered your question as you’ve asked it. As @Sven mentioned in a comment, the general solution to the question, “How do I make sure I never lose a file?” is to create a backup of the file. Make a copy of the file and store it in multiple places. In addition, if the file is extremely important and your company has a policy for backing up important data with a backup service, you might look into have this file included in the service.
On Linux the immutable flag is only supported on some types of file system (most of the native ones like
On filesystems where it’s not supported, another option is to bind-mount the file over itself in read-only mode. That has to be done in two steps:
mount --bind file file mount -o remount,bind,ro file
That has to be done at each boot though, for instance via
In a comment to the answer by Kevin, Jerry mentions:
Well, of course the file is being backed-up regularly, I just wanted another layer of protection against users which are sometimes working on the box with root user permissions. –
I’m going to assume that you can’t change this practice, as it’s a really, really bad idea.
All of the suggestions about using a read-only device have the same problem — it makes it a PITA for you to make legitimate changes when you need to. In the case of a lockable drive, such as an SD card, you run into the problem that you’re suddenly vulnerable when you unlock it to make your changes.
What I would recommend instead is setting up another machine as an NFS server, and sharing the directory with the important files to the machine(s) that the users have root on. Share the mount as read-only, so that the machines with users you don’t trust can’t make any modifications. When you need to legitimately make changes, you can connect to the NFS server and make our changes there.
We use this for our webservers, so that a successful exploit against the webserver won’t be able to insert or change any files that the server would then serve back out, or change the configuration.
Note that this can stull be bypassed in the same way that all of the mount-point related ones can be :
- Make a copy of the protected directory
- Unmount the directory
- Move the copy in place of the mount, or symlink it in if that mount doesn’t have sufficient space.
Why not create an ISO 9660 image, which is read-only by design?
Mount the ISO image, and it’ll look like a CD-ROM, but with the performance of a hard drive, and files on the mounted image will be just as safe from deletion as files on a physical CD-ROM.
The idea of burning the sensitive file to a CD and running it from a CD-ROM is interesting, assuming that setting the immutable bit on the file isn’t deemed sufficient.
There are potential negative issues with running it off a physical CD, including performance (CD-ROM drives are much, much slower than hard drives or SSD’s). There’s the likelihood of the CD-ROM being removed by a well-meaning individual and replaced with a different disc that they need access to. There’s the likelihood of a malicious party just taking the disc out and tossing it in a microwave (or the trash), thus “deleting” your file. There’s the inconvenience of having to have a dedicated hardware CD-ROM drive just for that one file, and other factors.
But the OP made it clear that the primary intent is to protect against accidental deletion, not against malicious acts, and that the file(s) in question is backed up and recoverable should an accident occur, but it is highly desirable that the file never be accidentally deleted.
It seems that running the file from a mounted ISO image would satisfy the requirement.
Kubernetes Free Online Tutorial, Kubernetes Beginner Tutorial
DevOps Free Online Tutorial, DevOps Beginner Tutorial
Ansible Free Online Tutorial, Ansible Beginner Tutorial
Docker Free Online Tutorial, Docker Beginner Tutorial
Openstack Free Online Tutorial, Openstack Beginner Tutorial
Disclaimer: This has been sourced from a third party syndicated feed through internet. We are not responsibility or liability for its dependability, trustworthiness, reliability and data of the text. We reserves the sole right to alter, delete or remove (without notice) the content in its absolute discretion for any reason whatsoever.