chown of file doesn't changed the ownership permanently when file is in home directory
 

Hi,

I'm doing the following in denka's home directory:

denka@tom:~$ ls -l test.txt
-rw-r--r-- 1 denka denka 5 Dec 28 20:01 test.txt

denka@tom:~$ sudo chown user:user test.txt

denka@tom:~$ ls -l test.txt
-rw-r--r-- 1 user user 5 Dec 28 20:01 test.txt

denka@tom:~$ vim test.txt -> make some changes and save the file

denka@tom:~$ ls -l test.txt
-rw-r--r-- 1 denka denka 10 Dec 28 20:19 test.txt

If I do the same in /etc, it works as expected. Why the ownership is not changed permanently when the file is in home directory?

Did the editor replace the file with a new one? It certainly looks like it did ... eighteen seconds later.

When you edit a file with vim (or most other editors) it creates a new file, then once that new file has been written successfully renames it to the old name. It does that for safety, to avoid losing everything if something goes wrong when writing the updated file. That newly created file will of course be owned by your UID.

One way to avoid that behavior is to create a second hard link to that file. In order to avoid breaking the hard link, the editor is forced to throw caution to the winds and write directly to the original file. You of course have to retain write premission to that chown-ed file in order to be able to do that. In your example, you do not have that write permission.

You are right, if I create hard-link with : ln test.txt test1.txt and change the ownership then test or test1 can not be edited anymore and the ownership stays.
Thanks!

Question: Why is the user denka able to overwrite a file it doesn't own and doesn't have write access to using vim? It seems to me that once the owner and group are changed to user:user, that user denka should be able to open the file in vim (as it's world-readable), but shouldn't be able to save changes to it.
When I duplicate the action on my server, I'm not allowed to save changes to the file.

The ability to delete a file and replace it depends on the directory permissions, not the file permissions. Yes, the rm command will warn you if you try to delete a file for which you do not have write permission, but that is just a courtesy warning. All you have to do is respond with "y" to remove the file. Other programs might or might not follow that convention.

If a directory has the "sticky" bit set in its permissions, then you have to own the file (or be root) to delete it. That feature is generally used in publically writeable directories like /tmp.

OK I've made the following test:
denka@tom:~/test$ ls -l
total 8
-rw-r--r-- 1 denka denka 6 Dec 29 13:49 test1.txt
-rw-r--r-- 1 denka denka 0 Dec 28 22:09 test2.txt
-rw-r--r-- 1 denka denka 0 Dec 28 22:09 test3.txt
-rw-r--r-- 1 denka denka 0 Dec 28 22:09 test4.txt
-rw-r--r-- 1 denka denka 14 Dec 29 13:50 test.txt
denka@tom:~/test$ vim test1.txt -> make some changes and save it
denka@tom:~/test$ rm test1.txt
rm: cannot remove 'test1.txt': Permission denied
denka@tom:~/test$ cd ..
denka@tom:~$ ls -ld test
drwxr-xr-x 2 user user 4096 Dec 28 22:12 test

As you said, even if denka is the file owner, denka can't remove the file, because user is the owner of the directory. But denka is able to edit it, so may be in some cases vim don't perform rm?

Yes, vim is smart enough to overwrite the file directly if it can't create a new file in the directory.