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?
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.
12For the interested, the bsd equivalent is
chflags schgDec 2, 2014 at 16:10
86Do note that a user with root access can unset that flag and then delete the file. That is unlikely to happen by accident but it does not prorect against intentional deletion.– GrantDec 2, 2014 at 16:42
6@Grant, not if the Securelevel is set high enough. The boot process sets the securelevel to 2 before the network is enabled, so resetting the flag requires local machine access (but this means that files used in the boot process before that time need to be immutable as well). Dec 2, 2014 at 17:38
17@Grant If one wants to take it to extreme, you can't prevent that the partition is deleted or the disk is put into a furnace or protons decay in 10^30 years ... Dec 2, 2014 at 21:27
2@Itai Ganot man I wish I had read it 4 days ago. I was a question in an examination I took =/– vfbsilvaDec 3, 2014 at 20:41
Burn it to a CD. Put the CD in a CD-ROM drive and access it from there.
16+1 for thinking out of the box. And, afaik, it has also been used before in some circumstances (black-box cdrom drive with cd in it shipped to its destination). It may not be appropriate if someone is able to disconnect the drive, anyway. Dec 4, 2014 at 16:49
1K.I.S.S. I love it! +1 Dec 4, 2014 at 20:56
2I think that's the correct answer to this question. Changing file attribute (chattr -i) can't prevent malicious actions. Dec 5, 2014 at 8:23
7These day a full-size SD card in a built-in cardreader may be a better solution - lower power consumption, faster access in many cases and more durable in no-write use.– Chris HDec 5, 2014 at 9:53
3@jpmc26 hence CD-ROM drive. Those are read/only. Dec 6, 2014 at 9:17
- 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
mount -o remount,rw readonlyfolder/ && rm readonlyfolder/permanent.txtDec 3, 2014 at 23:08
3Taking this a bit further, you can use
cramfswhich are compressed and read-only. It needs a special tool to build the filesystem.– Zan LynxDec 5, 2014 at 17:44
This may be a stupid question but what's to stop someone deleting readonly.img when it is not mounted... (if necessary dismounting beforehand)? Jan 25, 2020 at 11:23
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.
11Hard links won't protect the contents of the file. Dec 3, 2014 at 8:02
1However they will provide additional protection from DELETION, which was the original question.– barbecueDec 5, 2014 at 20:28
2@barbecue If the file is unlinked at the name an application looks for it at, it doesn't matter that the file's content exists under some other name. For anything looking for the file with the expected name, the file still has been deleted.– userDec 8, 2014 at 12:36
I think this is a rather good solution, possibly as one of several simultaneous safeguards. As barbecue says, the question was specifically about deletion. Secondly the consequence of someone discovering that the file is not present where it is expected to be bears no relationship to whether it is deleted. Scenario: "OMG, the file is gone!", response "Check the other hard link(s)" Jan 25, 2020 at 11:27
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.
How would you disable that? Oct 28, 2022 at 13:07
disable what that?– poigeOct 28, 2022 at 15:20
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.
2Well, 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.– user256033Dec 3, 2014 at 8:37
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 is it a "really, really bad idea" to back up an important file regularly and also make an effort to protect the original against accidental deletion? In the OP's original question, and from the OP's comment on the answer you referenced, it is clear that the concern is no malicious activity, but accidental/incompetent activity. Dec 7, 2014 at 19:54
1@Craig : it's a bad idea to have lots of users with root, especially if they aren't trusted to not mess with critical files.– Joe H.Dec 8, 2014 at 7:36
Ah... well of course it is. :-) But that wasn't the crux of the OP's question. The OP asserted that there are users with root access who should be protected against accidentally deleting a file. Dec 8, 2014 at 8:36
@Craig : it might not be the crux of the question, but it is the crux of the problem (XY problem?) ... but I have no idea what they're doing as root, so if they could make use of setuid and/or limited sudo privileges. And you should re-read the question, as I see no mention by Jerry that he's only trying to protect against unintentional removal ("i need to make sure it is not delete whatsoever"), and he only gave one follow-up that I see (which triggered my response).– Joe H.Dec 8, 2014 at 8:46
See the OP's response to this answer Dec 8, 2014 at 9:06
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.
1Root can still delete a file by manipulating the image directly. It is just a normal file which happens to be mounted. Dec 9, 2014 at 0:24
@ThorbjørnRavnAndersen How so? ISO 9660 by design is immutable. The party making that change would have to delete and replace the entire ISO file. Not that they couldn't do that. But they couldn't go in and surgically delete one file without tremendous expertise, if even then. It would be much easier to remove a physical CD-ROM from a drive and toss it in a dumpster. ;-) Dec 9, 2014 at 0:29
No need to be sophisticated - just overwrite the image file with zeros. Dec 9, 2014 at 0:51
@ThorbjørnRavnAndersen I'll concede that point easily enough. The caveat is that it would require intentionally dismounting the image and overwriting it. A thorough perp would just
shredit at that point. But unless you are denying physical access to the machine, it still seems easier to just pop a physical CD out of the drive and toss it in the dumpster than to dismount and overwrite the ISO file, although either is easy. And the OP has stated that the important file is backed up on a regular basis, so this is just an extra measure against accidental damage, not against malicious mischief. Dec 9, 2014 at 1:15
I've pointed out how to change an ISO9660 image even if it is supposed to be unchangeable. My point is that if a bit is writable at all, root can write it. Dec 9, 2014 at 12:43
chattr +imight help but will make the file read-only as well (and can be overriden with
chattr -i), also you can try to protected it with SELInux etc.