My question is similar to this other one, excepted that one asks about newly created files.

In my Unix box, users alice, bob and tomcat are in the group tomcat.

The configuration files of the Tomcat server are owned by the user tomcat, and in the group tomcat.

I have changed the permissions of this file to readable and writable by group so that alice and bob can edit the files.

However, I have noticed that after editing, the file becomes owned by the last user who edited it.

Q: Is it possible to change permissions so that Alice and Bob can edit the files, without changing their ownership?

How does editing a file change its ownership anyway?

  • Is your goal to ensure that tomcat continues to own the files, or is it to ensure that: the tomcat server continues to work; alice and bob can both continue to edit the files, and that security is maintained? Jun 1, 2017 at 20:18
  • 1
    I would assume that the tomcat service is running under user 'tomcat', based on the way your question is worded. This is probably not desirable since an exploit of tomcat could result in its own config being re-written to expose bits of your server that you may not intend. You should consider using a different group who can write the config, whilst the tomcat group can read, but not write.
    – Ed Neville
    Jun 1, 2017 at 21:09
  • 1

2 Answers 2


The resulting user of the file depends on what the editor does. Some editors save the file by truncating it, and writing over the file (without changing the inode). And some editors rename the file to another name (file to file~ is usual), and create a new file with the name of the original. Modifying the original file keeps the owner the same, creating a new one makes the new file owned by the UID of the creating process.

Of the editors I have on Debian, nano and joe, as well nvi and vim (the minimal version in vim-tiny) seem to overwrite in-place. Though I suppose vim and Emacs are probably configurable in what they do.

Stephen comments about atomic updates. The issue with re-creating in-place is that the file is truncated to zero length, then written. Another process could open and read it before all data is written.

An atomic update would be done by creating the new version as say file.new, then renaming file.new to file. Leaving a backup file, one could create file.new, link file to file~ and then rename file.new to file. The rename is atomic in that any process that accesses the file by name gets either the old or the new version, not anything in between. Any open file handles will of course point to the file that was held open, giving a consistent view on the file.

From the file permissions point of view, saving over the same file (inode) requires write access to the file itself (but not the directory), renaming it and creating a new one requires write access to the directory (but not to the original file).

(Renaming and recreating is also incidentally a way of fixing file permissions in case someone creates or modifies a file in a shared directory, but forgets to give group write access to it.)

  • 7
    Creating and renaming is also the only way to ensure that the file is atomically updated using POSIX semantics. Jun 1, 2017 at 20:37
  • nice explanation.
    – drmaa
    Jul 17, 2018 at 10:50

As explained by ilkkachu, if the editor being used creates a new file when saving, then there’s no way of controlling the owner of the file. What you probably really care about though is ensuring the files remain readable by Tomcat; you can do that by ensuring their group is tomcat (and they are readable by their group), and that can be enforced on new files by setting the setgid bit on the parent directory:

chmod g+s .

Thus, if bob edits a file using an editor which re-creates the file, the edited file will end up being owned by bob:tomcat and Tomcat will still be able to read it (with a typical umask at least). As long as the parent directory is writable by the tomcat group, any user in that group will be able to edit files in the directory (if only by re-creating them).

I would recommend however looking into changing your processes; you probably shouldn’t be editing files directly in the location they’re read from by Tomcat. Ideally, the files would be maintained in a VCS of some sort and deployed by a separate process (possibly automated). That way you avoid all these ownership issues...

  • nice solution!!
    – drmaa
    Jul 17, 2018 at 10:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .