3

I use archlinux x64. I'm studying web development and in order to edit files served by Apache under srv/http, directory which Apache serves, I created a group adding my user and Apache's user so I could edit the files without the need of moving them between directories.
The thing is, I can properly edit files within the directory with my user but whenever I save them, it's user and group reverts to my user and group. For example:

Me: user1:users Apache: http:http Directory ownership: http:development

Then I open the file /srv/http/index.html with my user, which looks like this...
rw-rwr-- 1 http development 1034 Mar 20 20:48 index.html
(as you can see it has read and write permissions to owner and to group) and when I save it, the file permissions reverts to this...
rw-rw-r-- 1 user1 users 1034 Mar 20 20:48 index.html

I fail to understand what's happening cause if I type groups to see my user active groups I get this lp wheel network video audio storage users development where indeed says I'm a member of development. I think its something else.
Could anybody tell me what's happening and how can I correct it at save time?
I know its not a big issue but I want to correct it before I get the lost hyphen like problem.

PD- I use sublime editor if matters.

Improve this question

2 Answers 2

Reset to default
4

In UNIX, only root can change the owner of files. As a consequence, we can conclude that the owner of the file is not changing when you edit it. Instead what must be happening is that your editor is writing out the edited contents into a new file and replacing the old file with the new one. Because it is a brand new file, the file ends up being tagged with you are the owner.

The are some advantages to updating files in this manner:

  • It is atomic: readers always see the old version or the new version, never a partially written new version.
  • It is easier to recover from errors. If an error such as disk full occurs, just delete the new temporary file (before renaming it on top of the old version) to roll back. If you were updating the file in place you might be left unable to complete and update and also unable to roll back.
  • You can "update" a file that you do not have write access to (because you never actually write the old file).
  • Any users that still have the file open can continue to use the old version as long as they need, so they are not disrupted. Useful for executable files!

There are also disadvantages:

  • You require write permission on the directory in which the file resides (or at least, somewhere else on the same filesystem), in order to create a new temporary file in it and then rename that temporary file.
  • You cannot preserve the owner of the file and you may or may not be able to preserve its group.
  • There is a long laundry list of other things that you might preserve by replicating them in the new temporary file before moving it in place, such as the permissions, the extended attributes, whether or not the file is a symlink to an actual file elsewhere, resource forks (MacOS), etc... Unless you are very careful and very exhaustive, it's hard not to miss one or more of those.

So it's a compromise.

Automated tasks such as background scripts, software installation, and the like, usually opt for replacing the old version with a brand new file, especially because of atomicity.

Text editors and other human tasks usually opt for editing the file in place.

I am unfamiliar with your editor, but it appears to be making the opposite choice that most other editors make. You will have to see if you can configure it to stop doing that.

By the way, it's actually much better if the owner of files inside your document root are owned by you, not by the apache user. It provides better assurance that the web server (if compromised, for example) cannot edit the files. So you might consider ignoring this particular "problem" and considering it a good thing.

Improve this answer
5
  • I understand, so sublime is actually replacing the file opposite as normal editors do. I'll research how to control that just in case it comes in handy, now I would ask a new doubt...doesn't the web server needs write permissions to handle the files it serves? Or just with read and execute perms are enough? Cause I see the point in the last you say, thanks for the clearance by the way and maybe I'm getting confused, it needs permissions but not the ownership...is that it? Commented Mar 21, 2015 at 19:30
  • I don't know what proportion of editors replace files in place, but that is not recommended, because it leaves an interval of time where the file is broken (if another application tries to read the file mid-save). Good editors do this as a fallback option, only when they can't write to the directory or when they couldn't otherwise preserve ownership. Commented Mar 21, 2015 at 21:28
  • @Kronos A web server only needs to read the files it serves (unless it runs scripts that need to modify files, in which case only these files should be writable by the web server, never e.g. the script files themselves). Commented Mar 21, 2015 at 21:29
  • @Gilles Vim for one rewrites files in place. Despite the unfortunate interval of time where the file is broken, it's still the de facto standard behaviour for editors. Replacing the file with a new one is just fraught with complication. It's just too hard to think of everything. In addition to all the usual stuff like making sure you don't break a hard link or replace a symlink with a new regular file or mess up the permissions or owner or group, you have to work hard to preserve every other non-portable thing under the sun that the developer might not even be aware of: acl, xattr, forks, ... Commented Mar 21, 2015 at 23:26
  • @Celada I understand thanks, and I agree with Gilles, editors should open files as the default but as you say, it's not that easy to take all possible considerations Commented Mar 23, 2015 at 5:01
2

Yes, some editors will basically delete the old file with the new edited file. Thus the owner is the one that made the edit and the group would be your primary group.

However, you enforce the group on files under the directory by changing the directory permissions using chmod g+s . .... this will cause any newly created file to be in the same group as the directory is even if this is NOT your primary group.

Still one downside to using group write permissions to do things is that you should change your umask to at least 002 so that it will create group writable files.

Improve this answer
2
  • so what the "s" in ` chmod g+s` is enforcing the same group permissions of the actual directory? Is it the sticky bit? Commented Mar 21, 2015 at 19:33
  • This is the SETUID bit on the directory will set the files under it when created with the same group as the directory. 's' is NOT a sticky bit! See your man page for chmod for more information. Commented Mar 21, 2015 at 21:10

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.