I tried to protect a file with root owner (permission 555) inside my home login directory (e.g. /home/demo).
But the file still can be removed/deleted by my login account.

E.g.
user login: demo
home dir : /home/demo
Then I create a file with root owner in /home/demo & with only read & sticky bit.
However, the file still could be removed by 'demo' user.

I also tried to change my home dir (/home/demo) permission to 755 & owned by root. But then I have problem logging into the account using 'demo' user now. It complains it does not permission to write into files.

Any advise ?? thanks.

man chattr on 'i' flag - if you are on ext[23] fs then 'i' flag should make file immutable. Only settable by root (good).

The operation of removing, or unlinking a file is an operation on the directory where the file is listed and not on the file itself. So the read-only attributes will not protect it unless the directory it is has the sticky bit set. However the owner of the directory will be able to remove the sticky bit and then remove the file. If the file is in a root owned subdirectory, then it may be protected from deletion if both the directory and file are readonly. I don't think that the regular user can delete the directory if it isn't empty, and since the file is in a root owned directory it is protected.

Someone elses home directory is not a good place for root to be saving files. Maybe if you explained what you are trying to do, someone could suggest another way.

I agree with jschiwal. It's a very bad thing to save root's files in other people's home directories.
Not only can they delete the files (unless sticky bit on directory is set and root owns the directory and EVERY parent uptil the / directory), they can also rename or move them, thus changing permissions/ownership.
This way, any "sensitive" information (like passwords) in the file can be read by the normal user.

As jschiwal said, it really depends on what you want to do.
If you want some of your normal users to issue some commands that are typically reserved for root only, try using "sudo" (but use it wisely).
Or try using user groups with specific permissions.

I guess it is for anauthorized-access (demo username suggests it) box. So some configuration files like .bashrc are immutable. In this case my solution with chattr +i <file> will work.

I think that you need to use ext2 or ext3 in order to use the chattr command.
Using ulimit, PAM and the permission system may be a better way of restricting what a user can do.

I you make the ~/.bashrc file immutable for example, you prevent legitimate changes to the shell environment.
Using ulimit, PAM, and the permission system are better ways to protect the rest of the system from abuse.

Yes, as I said.

Well, how can I not let user delete a file in his own directory in other way?

In some cases they are not legitimate. If user is not supposed to return to this box with reasonable probability, and login is shared. Something with public access, maybe.

Sometimes uniform user settings are also needed.
Really, it depends on final purpose.. I see some where chattr is suitable. Topic-starter can say if I guessed.

Also on XFS, JFS, ReiserFS, NFS, ..

Couldn't say about XFS/JFS/ReiserFS - chattr doesn't claim standard conformance, and I haven't used the mentioned filesystems. For NFS it depends on underlying FS, doesn't it?

Hi thanks for the reply. i tried chattr +i <file>. It works & only the root can remove it (just need to chattr -i <file> to reverse it).
It is exactly what i need. I just need to protect some files inside my authorised-user login, this is to prevent the files being accidentally remove by the user.