2

I use Geany to edit files in a web app that resides in /var/www. The owner and group of /var/www and all sub directories and files are www-data:www-data. My user account is a member of that group and I edit the files as my user. Sometimes it seems Geany changes the owner and group of the edited file to my user and my group.

How can I make sure the user:group is never changed when I edit a file with Geany?

I found this clue in the Geany help:

use_atomic_file_saving

Defines the mode how Geany saves files to disk. If disabled, Geany directly writes the content of the document to disk. This might cause loss of data when there is no more free space on disk to save the file. When set to true, Geany first saves the contents into a temporary file and if this succeeded, the temporary file is moved to the real file to save. This gives better error checking in case of no more free disk space. But it also destroys hard links of the original file and its permissions (e.g. executable flags are reset). Use this with care as it can break things seriously. The better approach would be to ensure your disk won't run out of free space.

As of now it's disabled, meaning that the file is written directly, which I thought would prevent my problem from happening.

This questions contains some relevant info: How do I edit a file and preserve its access control list / SELinux security context?

Community
  • 1
PetaspeedBeaver
  • 1,356
  • 2
    I thought it was a bad idea to have your www files owned by www-data, because if your server is compromised, you don't want the user gaining access to change the files. – P Daddy Mar 30 '16 at 15:56

1 Answers1

1

Looking at Geany's wiki, it looks like you might also need to disable this option:

use_gio_unsafe_file_saving

This is on by the default, and is provided by the GIO library.

<p>This option attempts to deal with as many of the issues associated with the other methods as it can:</p>

<ul>
<li>It attempts to use the atomic rename saving method described above, but tries to address as many issues as it can:

<ul>
<li>it checks metadata of the temporary file and tries to copy the metadata from the existing file,</li>
<li>if the metadata is correct, it writes to the temporary and renames as above,</li>
<li>if the metadata is not correct, it uses a non-atomic but safe method of:

<ul>
<li>copying the existing file to a temporary file</li>
<li>truncating and overwriting the existing file, if this fails the temporary file should be copied back or available, but see disadvantages below.</li>
</ul></li>
</ul></li>
<li>It attempts to determine if rename is available on the underlying file system, and uses the non-atomic method if rename fails.</li>
</ul>

<p>Advantages:</p>

<ul>
<li>Deals with the most different conditions, so works the most correctly on the most file systems. That is why it is the default.</li>
</ul>

<p>Disadvantages:</p>

<ul>
<li>There is a <a href="https://bugzilla.gnome.org/show_bug.cgi?id=602412" rel="nofollow">long standing bug</a> or design fault in the GIO library that deletes the temporary file from the non-atomic save if writing the data file fails. <strong>This means it is no more safe than the simple overwrite method since the previous data is not restored, or even left available for the user to restore.</strong></li>
<li>The non-atomic save copies data over the network three times (read and write to make the temporary file, write the output file) which can be slow on remote networks.</li>
<li>Uses twice the disk space.</li>
<li>Is quite complex.</li>
<li>Uses library code so Geany can't modify its behaviour</li>
</ul>

What a strange method of file saving. It appears that it can result in the same "atomic" save as the use_atomic_file_saving option.

P Daddy
  • 375
  • Looks very likely that this was the catch! :) I will try this for a couple of days of work, and come back with feedback when tested. – PetaspeedBeaver Mar 30 '16 at 15:56