Re: deny deleting a file for users

From: Glynn Clements (glynn.clements_at_virgin.net)
Date: 05/31/03

  • Next message: Jimi Thompson: "Re: Linux firewall/IDS/NAT suggestions" 
    Date: Sat, 31 May 2003 03:51:19 +0100
To: Sandra Hernandez <sandra@fib.upc.es>

    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 <glynn.clements@virgin.net>
  • Next message: Jimi Thompson: "Re: Linux firewall/IDS/NAT suggestions"

    Relevant Pages

    • Re: [PATCH v3] vfs: new O_NODE open flag
      ... For example even without the possibility of hard links ... there's still a race in udev in the following course of events: ... open passes permission checks ... driver intended for other user gets loaded ...
      (Linux-Kernel)
    • Re: Changing permissions of ps command
      ... >if you set up permission to on comand and not hard links ??? ... less likely to break patchadd. ...
      (comp.unix.solaris)