If the write permission of the file is disabled, no one can change the file.
The chattr +i FILE also can protect the file from change.
Let me know what the difference, and when we should use chattr +i rather than chown -w.
chattr +i sets the immutable filesystem attribute on the file. It differs from access control rules. Access control rules apply to the file attributes, while immutable is a filesystem extended file attribute, which may not be available on all filesystems. Only a user with root privileges can set or unset this extended attribute. Nobody, not even the owner or a user with write permission, can write into such file. A user without write file permission can create a hard link to a regular file, but if the file is marked as immutable, a user cannot create a hard link, since the filesystem cannot change the references count to this immutable file.
chattr +i is useful for protection from accidental deletion by root. Also an immutable file cannot be renamed or moved from one directory to another.
From chattr man page
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.
As you can see , chattr is more powerful than chmod. chmod -w removes only 'write' permission to the file content. And also you need to use chattr +i to protect/lock the file then chattr -i to unlock
chmod -w file is available on all UNIX environment, however chattr -i FILE using extended file attributes might not be available on your system, depending on the type of the File System/Distro!
Apart from that, have a look at this link for the good and bad points of employing extended file attributes.
Related
I have created directory and set read only permission for root using chmod.
chmod -R 400 some_dir/
but when I try to create any file inside it using touch, I was expecting error message something like
touch some_dir/hello.txt
"touch: cannot touch `some_dir/hello.txt': Permission denied"
but it creates file "hello.txt" inside it happily, but directory permission if I check it still shows readonly for root. Please explain what I'm missing here, since I was expecting error message which would be displayed if any other user(apart from root) try to create file in that directory?
PS: I'm running as root user.
Short answer is - Yes, Root user can create files in a directory that is marked as Read Only. You may argue - why? But that's the whole point of root account. It's a special user and it can do things that others can't.
If you want to prevent the file from accidental modifications, you can set the i attribute of the file on with chattr +i command. This will make the file unchangeable. However, note that it will only prevent accidental modifications. Root users can still just unset the attribute first and then modify the file.
I can not delete this directory admin when under the root permission. Can anyone help?
This is mainly due to the improper uninstall of the Vesta control panel. And the file attributes are shown here:
-------------e- admin/conf/mail
-------------e- admin/conf/web
-------------e- admin/conf/dns
and the attributes for directory admin are:
----i--------e- admin/conf
It seems the attribute i is causing problems, that attribute means the file is immutable.
With files like this not even root can change them, you need to change permissions first and then try to delete.
if you have a ext2, 3 or 4 filesystem you can use the chattr command to change the attribute.
Try executing the command:
>sudo chattr -i {filename}
This commands removes the attribute, and you should be able to delete the files.
If you want to set this bit to another file, is a trick to secure some files from deletion even from root, you can try:
>sudo chattr +i {filename}
If I would like to lock a file as read-only. Even root can not use an editor to modify it, just allowing any program to open it read-only.
Any suggestions?
There is an "immutable" bit for files.
Programs (even running as root) won't be able to tamper with the file. Of course, root can un-do the bit, but most programs (especially non-malicious ones) won't get past it.
Set it with
sudo chattr +i file
you should have root perms
sudo chattr +i file
You can use Perl or another language to create a file lock
How do I lock a file in perl
But, root could kill the process can gain access to the file.
Why is it possible to touch a write-protected file?
Shouldn't the following give an error?
$ touch test.txt
$ chmod a-w test.txt
$ ls -l test.txt
-r--r--r-- 1 name group 0 Jun 13 09:14 test.txt
$ touch test.txt && echo OK
OK
$ ls -l test.txt
-r--r--r-- 1 name group 0 Jun 13 09:15 test.txt
Does touch change permissions, touch the file, and change permissions back? Why would it do that?
Given this behavior, if I really want to protect a file so that I (my user) will never (unintentionally) change, remove or change its timestamp in the future -- how can I do it?
(Sorry, not strictly programming-related, but slightly, and probably of interest to many programmers.)
From the touch (coreutils) documentation:
If changing both the access and
modification times to the current
time, `touch' can change the
timestamps for files that the user
running it does not own but has write
permission for. Otherwise, the user
must own the files.
The execution permissions of the directory that the file contains dictates the ability to delete or modify the inode information for the entry in the directory that is associated with the file.
As the comment below indicates I have glossed over the technical reason but instead offered a reasoning why the behavior might not be as expected. Since you can execute in the directory there are a number of things you can do to tinker with the file and I am going to leave it at that.
If you want to stop anyone but root from modifying a file the best method is to use the chattr +i filename on the file. Even root will not be able to perform any actions on it without running chattr -i on it. This applies to Linux so YMMV.
Here's the relevant output from : strace "touch test.txt"
open("test.txt", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_LARGEFILE, 0666) = -1 EACCES (Permission denied)
futimesat(AT_FDCWD, "test.txt", NULL) = 0
It indeed gets a "Permission denied error" on the open(2) system call regarding EACCES. See relevant section in utimes(2) man page.
However, it does succeed in updating the timestamp using the futimesat(2) system call.
As others have indicated, it looks like the directory permissions hold the rights to update access/moficiation timestamps.
You can, however change the attribute of a file to immutable using:
chattr +i test.txt
Note: Only root can do this, and it's a very harsh way to disable access to files. But in extreme cases, it can be useful. In addition, this is an ext2/3/4 feature, not available on other filesystems as far as I know.
You can update the modification time if you own the file, regardless of write permission. (It is not related to any permission on the directory.)
From POSIX.1-2008:
Only a process with the effective user ID equal to the user ID of the file, or with write access to the file, or with appropriate privileges may use futimens() or utimensat() with a null pointer as the times argument or with both tv_nsec fields set to the special value UTIME_NOW. Only a process with the effective user ID equal to the user ID of the file or with appropriate privileges may use futimens() or utimensat() with a non-null times argument that does not have both tv_nsec fields set to UTIME_NOW and does not have both tv_nsec fields set to UTIME_OMIT. If both tv_nsec fields are set to UTIME_OMIT, no ownership or permissions check shall be performed for the file, but other error conditions may still be detected (including [EACCES] errors related to the path prefix).
In layman's terms, using the touch command will update or create a file without editing/modifying its contents. Because the command doesn't(and can't) write or erase anything from the file, it can be used on write-protected files. See the wiki on the touch command for more information: http://en.wikipedia.org/wiki/Touch_(Unix)
I have a bunch of long-running scripts and applications that are storing output results in a directory shared amongst a few users. I would like a way to make sure that every file and directory created under this shared directory automatically had u=rwxg=rwxo=r permissions.
I know that I could use umask 006 at the head off my various scripts, but I don't like that approach as many users write their own scripts and may forget to set the umask themselves.
I really just want the filesystem to set newly created files and directories with a certain permission if it is in a certain folder. Is this at all possible?
Update: I think it can be done with POSIX ACLs, using the Default ACL functionality, but it's all a bit over my head at the moment. If anybody can explain how to use Default ACLs it would probably answer this question nicely.
To get the right ownership, you can set the group setuid bit on the directory with
chmod g+rwxs dirname
This will ensure that files created in the directory are owned by the group. You should then make sure everyone runs with umask 002 or 007 or something of that nature---this is why Debian and many other linux systems are configured with per-user groups by default.
I don't know of a way to force the permissions you want if the user's umask is too strong.
Here's how to do it using default ACLs, at least under Linux.
First, you might need to enable ACL support on your filesystem. If you are using ext4 then it is already enabled. Other filesystems (e.g., ext3) need to be mounted with the acl option. In that case, add the option to your /etc/fstab. For example, if the directory is located on your root filesystem:
/dev/mapper/qz-root / ext3 errors=remount-ro,acl 0 1
Then remount it:
mount -oremount /
Now, use the following command to set the default ACL:
setfacl -dm u::rwx,g::rwx,o::r /shared/directory
All new files in /shared/directory should now get the desired permissions. Of course, it also depends on the application creating the file. For example, most files won't be executable by anyone from the start (depending on the mode argument to the open(2) or creat(2) call), just like when using umask. Some utilities like cp, tar, and rsync will try to preserve the permissions of the source file(s) which will mask out your default ACL if the source file was not group-writable.
Hope this helps!
It's ugly, but you can use the setfacl command to achieve exactly what you want.
On a Solaris machine, I have a file that contains the acls for users and groups. Unfortunately, you have to list all of the users (at least I couldn't find a way to make this work otherwise):
user::rwx
user:user_a:rwx
user:user_b:rwx
...
group::rwx
mask:rwx
other:r-x
default:user:user_a:rwx
default:user:user_b:rwx
....
default:group::rwx
default:user::rwx
default:mask:rwx
default:other:r-x
Name the file acl.lst and fill in your real user names instead of user_X.
You can now set those acls on your directory by issuing the following command:
setfacl -f acl.lst /your/dir/here
in your shell script (or .bashrc) you may use somthing like:
umask 022
umask is a command that determines the settings of a mask that controls how file permissions are set for newly created files.
I don't think this will do entirely what you want, but I just wanted to throw it out there since I hadn't seen it in the other answers.
I know you can create directories with permissions in a one-liner using the -m option:
mkdir -m755 mydir
and you can also use the install command:
sudo install -C -m 755 -o owner -g group /src_dir/src_file /dst_file