After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 578630 - File Creation Permission Bug Only for Some File Types: Creating as 644 (rw-r--r--) when should be 664 (rw-rw-r--)
File Creation Permission Bug Only for Some File Types: Creating as 644 (rw-r-...
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
2.6.6
Other All
: Normal normal
: 2.8
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2009-04-10 16:29 UTC by Jay Smith
Modified: 2009-06-15 17:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jay Smith 2009-04-10 16:29:55 UTC
Please describe the problem:
Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux.

(In my experience) When creating (saving new, untitled) TIFF (.tif) files, the files are being created with permissions of Creating as 644 (rw-r--r--) when should be 664 (rw-rw-r--).

=== 

On Gimp-developer list, 10 April 2009, Martin Nordholts stated the following in reply to my query on this problem:

"This happens to me as well and from looking at the code it also happens 
for gbr, gih, pat, pnm and raw which opens a file for writing like this:

  fd = g_open (filename, O_CREAT | O_TRUNC | O_WRONLY | _O_BINARY, 0644);

E.g png instead uses

  fp = g_fopen (filename, "wb");

This inconsistency doesn't make any sense, feel free to open a bug 
report. The latter is identical to the former apart from the 
permissions, so we probably want to use the latter for all plug-ins."

===

On two different workstations, being run by two different login users, creating files in various different directories, Gimp is creating the files with permissions that are incorrectly too restrictive:

  Gimp is making as 644:

  -rw-r--r--  1 jay jsa  1919194 2009-03-31 12:10 tmp.tif

  When it should be making as 664:

  -rw-rw-r--  1 jay jsa  1919194 2009-03-31 12:10 tmp.tif

Only Gimp is doing this.

Creating files in the exact same manner and saving them to test.png or test.jpg results in _correct_ permissions.  (It only is a problem with .tif files so far in my testing, but above Martin Nordholts reports the problem with certain other filetypes as well.)

a) The directories that the files are being created in have perms of 6775:

   drwsrwsr-x  3 jay     jsa     4096 2007-05-28 15:57 testdir

   Files created in a directory with those perms are _supposed_ to be
created as 664 which is rw-rw-r--.

b) When any other program, such as vi or touch, makes a file in the very same directory, it is making the perms correctly (664).

c) I have double checked the user's umask which is correctly 0002 which would result in correct file creation as 664.

d) We have never had this problem with any other program (when the directory perms are correct, which they are in this case).

e) An associate on a completely different, but virtually identically configured Ubuntu linux system (all same versions). has been able to replicate the exact same problem.

Steps to reproduce:
1. Create a new image file in Gimp.

2. Save the image file as a TIFF .tif file, in a directory that has perms that would normally cause a file to be created with perms of 664 rw-rw-r--. 



Actual results:
The file is saved with perms of 644 or rw-r--r--.

Expected results:
The file should be saved with perms of 664 or rw-rw-r--.

Does this happen every time?
Yes for .tif files.  Another reporter (see above) says that it is also happening for: gbr, gih, pat, pnm and raw. 

Other information:
In a multi-user workflow, this is a major annoyance as files cannot be edited by the next user without first changing permissions.
Comment 1 Martin Nordholts 2009-04-10 17:05:18 UTC
Let's fix this for 2.8
Comment 2 Michael Natterer 2009-06-14 18:47:18 UTC
Unless I'm confused, the fix here is as simple as replacing 0644 by 0664,
right? The mode will run through the user's umask anyway.

(I agree using g_fopen() all over the place would be nicer, but since
 we have a fix at hand, this shouldn't block fixing this bug quickly)
Comment 3 Jay Smith 2009-06-14 19:21:40 UTC
From the OP.

Correct, 0664 is what is needed and will then be accessible as the OP desires.

But, just as a point of order, it would seem to me (the OP) that other people might want files created according to the perms defined in/by the directory in which files are being created.  Hardwiring to 0664 fixes the OP's problem, but might actually create problems for users who want and are expecting the perms to be tighther (and for whom they have been tighter, if only accidentally). 
Comment 4 Michael Natterer 2009-06-15 07:49:10 UTC
But this is exactly what umask is for, isn't it? So if the user's files
were created with tighter permissions for whatever reason, that reason
can only be umask.

I think I'm simply going to apply the trivial fix here.
Comment 5 Michael Natterer 2009-06-15 17:12:36 UTC
Hm, actually, the right permissions to pass to open() are 0666, which
is exactly what fopen() does when you create a file. This way both
versions of creating a file are really consistent.
Comment 6 Michael Natterer 2009-06-15 17:31:01 UTC
Fixed in master:

commit 6049768abf710fa78f4c87e426ef045d142bdd79
Author: Michael Natterer <mitch@gimp.org>
Date:   Mon Jun 15 19:28:06 2009 +0200

    Bug 578630 - File Creation Permission Bug Only for Some File Types:
                 Creating as 644 (rw-r--r--) when should be 664 (
    
    Use 0666 as permissions instead of 0644 and let the user's umask care
    about restricting, so creating a file with open() behaves the same way
    as with fopen().

 app/widgets/gimpwidgets-utils.c  |    2 +-
 plug-ins/common/file-gbr.c       |    2 +-
 plug-ins/common/file-gih.c       |    2 +-
 plug-ins/common/file-pat.c       |    2 +-
 plug-ins/common/file-pnm.c       |    2 +-
 plug-ins/common/file-tiff-save.c |    2 +-
 tools/test-clipboard.c           |    2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)