Make file in linux readonly
Is there a way to make a file readonly permanently in linux. Or can I put a password to a file to make it readonly, then apply that password again to change its permission, or before they can alter it.
Like it’s pointed out by Sami-Laine , you can’t. However, if you’re the admin & the person to know the root password you can. And not to mention recovering root password when you’ve access to hardware.
Not really, you could use chmod 600 to make the file only read/writeable by you (and root) or do chown root:root so that only root password can change permissions. Either that or encrypt the file.
Who are you protecting against, or in other words, who would still be allowed to make the file read-write? You can’t do anything that the system administrator or someone with physical access can’t undo.
2 Answers 2
Only way to do that would be to write the file in question on a media which is writable only once, e.g. a CD-ROM.
Any other solution is possible to circumvent by root. If the file you’d like to make non-writable is one of system files, e.g. /etc/passwd , you’d either have to to live with many files being read-only or create a symlink from the file you want to protect, e.g. /etc/passwd to a file residing on your read-only media, but that again would be easy to circumvent by root , simply delete the symlink and create new content in its place.
So simple answer would be: No and there must be a better way of achieve whatever it is that you want to accomplish by making one or more files permanently read-only.
Make file read only on Linux even for root
Put it on a CD or a DVD. The once-writable kind, not the erasable ones. Or some other kind of a read-only device.
Ok, I suppose you want a software solution, so here are some ideas: You could possibly create an SELinux ruleset that disables the syscall (*) that chattr uses, even for root. Another possibility would be to use capabilities: setting +i requires the CAP_LINUX_IMMUTABLE capability, so if you can arrange the capability bounding set of all processes to not include that, then no-one can change those flags. But you’d need support from init to have that apply to all processes. Systemd can do that, but I think it would need to be done for each service separately.
(* maybe it was an ioctl instead.)
However, if you do that, remember that a usual root can modify the filesystem from the raw device (that’s what debugfs is for), so you’d need to prevent that, too, as well as prevent modifying the kernel (loading modules). Loading modules can be prevented with the kernel.modules_disabled sysctl, but I’m not sure about preventing access to raw devices. And make all the relevant configuration files also immutable.
Anyway, after that, you’d also need to prevent changing the way the system boots, otherwise someone could reboot the system with a kernel that allows overriding the above restrictions.
There is no way to do this. SOMEONE will always be able to revert the file to a writable status, unless it’s on read-only media like a CD-ROM. You can effectively prevent root from doing so using SELinux permissions (I don’t know how to do so, or I would provide an example), but then the user that does have permissions would still be able to undo things.
What you want is Mandatory Access Control. It allows you to specify a set of permissions which the kernel will not allow to be overridden, even by root. SELinux is one well-known such system, Smack is another example, and AppArmor is a third such system. In Linux, they are implemented as Linux Security Modules, a general-purpose facility for controlling access outside the traditional UNIX-like security model. In addition to the existing general-purpose systems, you could of course create your own for a special purpose.
Of course, root has the ability to turn the entire facility on or off or change the MAC permissions of files, and some of these systems even allow those capabilities to be granted to non-root users. However, it’s also possible, depending on the system, to disable this ability. I know SELinux and Smack make this possible; I doubt all LSMs do. Once disabled, the only way to regain the ability is to reboot the kernel. You will then want your boot process to disable the capability before user access is enabled. If your kernel and boot process are secure, such a configuration could (at least in theory) be changed only by physically removing the storage media to change it.
As an example, if you were using SMACK, you could do:
This would set the file to have the special label «_» which allows only read or execute access, but never write. Now even root cannot write this file (once SMACK has been activated and the security override capability has been disabled, as mentioned above).
However, you must also ensure that your kernel is secure. By default, it is easy for root to subvert the kernel, because the kernel trusts the root user. If root can just remove the security module, it doesn’t help very much. A list of such methods is here, but note that no such list can ever truly be complete for all circumstances.
Finally, depending on your circumstances, you may need to secure your boot process. For a machine where you have sole physical access, this might not be needed, but for maximum security you really want encrypted filesystems and a secure way of booting the kernel, such as UEFI Secure Boot.
make file appear readonly to a library function
I’m using a library that can read or write some metadata that I need from files. I only need to read and I know that my files are on slow storage. I noticed that while reading the values I need is very fast, closing the files is slow. Basically, if I open(); read(); close() each file my program is quite slow, but if I only open(); read() during operation and close() right before exit (i.e. I let my run-time close the files during finalization of the leaked objects) the program runs fast, but stops for several seconds just before exit — when the files are being closed. On the other hand, if I remove write permission from the files this doesn’t happen: it seems that files open readonly are closed much faster than the files open read-write. It could be that the library writes metadata on close «just to be sure» if the file is writable, or some other reason, but anyway — it’s impossible to specify for the library that I wan’t to open the file only for reading: it tries to be intelligent and decides based on file permissions. At the moment to speed things up I’m changing file permissions just before opening it and restoring permissions after the metadata is read. It works, but it feels wrong. Is there a way in linux / unix to make files appear readonly to the current process temporarily? I can’t use setuid(2) because the program is ran by unpriviledged user (or am I wrong about this?). details The library is taglib-ruby which is in turn a wrapper around taglib’s C++ API. The program may list the tracks on the device and needs to know their length in seconds (the reason I use taglib), but the same media will be written to (new tracks uploaded, some tracks deleted) hence I can’t just force users to mount the device readonly. I realize that a better solution would be patching taglib to allow to specify that I just want to read the metadata, then patch taglib-ruby to wrap the new API. But I’m not up to it, plus I have a workaround already, thus not much insetive to go down that route. I’m just wondering if there is a better workaround.
Is it the library that calls the open() function, or is it you opening the file and passing a FILE * as argument to functions from the library?
remount the directory using «-bind,ro» switch. And ask taglib to operate on read-only filesystem. It should stop library from opening file in write mode.( not sure if -bind switch is supported on all distributions )
Sorry, I don’t understand. You access the file and then the atime is updated on a close() . This causes a write() to the file system. Also: relatime. At the very least, you can rule out atime by a mount with noatime. Mounting with ro will have the same effect as per Icarus3. I guess the library maybe re-writing something; is the modified time updated? At least that could provide helpful information.
As well strace -e trace=open,write,close might be helpful. You will get a brief overview of what is being written, if that is the case.
IOStream * stream = new FileStream («/path/to/file», true);//true means open in read mode only File * file = new File( stream ); //constructor is protected, so extend File class FileRef fileref( file ); //now use fileref.
Make files read-only unless accessed by symlink path
my question is two-fold: (a) is there a way to make all files in the ro directory read-only, but if the files are accessed by way of the symlink, make them writable? (b) the reverse of (a): is there a way to make the files writable only if they are accessed directly? This is just for *nix/MacOS
Do you have a use case for this, or is it pure curiosity? If you have a use case, we might come up with an alternative way to do the same thing.
@Amadan well the only alternative I can think of is just rsync -r , but the problem with that is the y don’t mirror each other when the original files change which they will.
I can see by rep you are not a newbie, so I was trying to be a bit more circumspect in suggesting this might be an XY problem 🙂 I don’t mean «alternative to access control by path», I meant are you sure your underlying problem can’t be solved with the usual permission system, groups, and/or ACL, or maybe some other method? What is the scenario you are trying to use this in?
Yeah I am mostly curious, if there are any good solutions related to the question, they are relevant. Basically, I am trying to prevent someone from making changes to a file that will get overwritten later by a command line tool. The tool spits out files, the files will be read-only, or there will be some mechanism to tell the user that modifying the files is a waste of time b/c they will be overwritten later.
Linux usually does that just with comments inside the autogenerated file, and trusts users with sudo authority not to be idiots 😀 If the tool is a binary executable, you can set it to setgid with a group that has write permissions to the directory. e.g. drwxrwxr-x amadan writable file , with drwxrwsrwx amadan writable utility ; this would allow only members of writable group to edit the file, as well as the utility , regardless of the user who runs it.