Sandra Hernandez wrote: > I would like to know if there exist any way to deny deleting a file for a user, but > allow this user accessing, removing parts of this file or append text?
If they neither own nor have write permission on the containing directory, they can't create or delete files within that directory. If they don't own the containing directory and it has the sticky bit set (chmod +t ...), they can't delete files which they don't own from that directory. In both cases, the ability to read and modify files depends upon the ownership and permissions of the files themselves. An alternative approach would be to rely upon the fact that a file is only actually *deleted* when its link count reaches zero. If you create a directory on the same filesystem (hard links cannot span filesystems) to which users don't have write permission, then populate it with hard links to the users' nsmail files, even if the user does "delete" the file (i.e. "rm ..../nsmail"), the contents are still available via the remaining hard link. However, if the user deletes or renames the nsmail file, then creates a new version, the new version won't be protected until you create a hard link to it. So, you would need to do this on a regular basis. It's similar to performing backups, except that you aren't actually copying the data, so it will be quicker and use less disk space than a backup. > We have problems in our systems because some users delete theirs own > nsmail file without notice what they are doing. Unfortunately, there's only so much that can be done to protect a user from themselves; OS security models aren't designed to deal with this issue. -- Glynn Clements <[EMAIL PROTECTED]>
