eog (Eye of Gnome) ignores umask settings

Bug #792145 reported by Dan Stoner on 2011-06-03
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Eye of GNOME
Fix Released
High
eog (Fedora)
Won't Fix
High
eog (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: eog

This does not seem to be a generic Gnome or gnome-vfs bug (some similar bug reports exist for earlier Ubuntu releases), I have only been able to reproduce it in eog.

Expected Behavior:
Rotating an image and saving it should not change / break group permissions on the file. Expect that eog will respect system umask settings in the same way that other Gnome applications do.

What Happens:
Rotating an image and then clicking "Save" changes the permission so only the owner has read/write, all group permissions are removed. eog seems to be hard-coded to a specific umask rather than respecting the system configuration. This breaks group access to image files that have been rotated by other members of a group.

To reproduce:
1. Change system umask from default (probably 022) to 002 (I am not exactly sure of minimum needed to do this, I added "umask 002" to a dozen files before realizing that the bug was only in eog, not a generic Gnome issue.
2. Open an image in eog. Rotate the image. Save the image.
3. Observe that the group permissions on the file are now gone (e.g. only owner has rw).

More detailed instructions:

1. Change system umask settings, reboot [NOTE: what is official minimum method for setting umask for Gnome apps?].

Confirm current system umask settings and the umask used by Gnome apps
$ umask
0002

$ touch picture.txt

$ nautilus
Create an empty file using File--> Create Document--> Empty File
[I called the new file picture.empty]

May need to chmod some group permissions before performing the test. In this case, we use an existing image file named picture.jpg
$ chmod g+rw picture.jpg
$ chmod o+r picture.jpg

$ ls -al picture*
-rw-rw-r-- 1 dan 5000 0 2011-06-02 20:37 picture.empty
-rw-rw-r-- 1 dan 5000 1395326 2011-06-02 20:15 picture.jpg
-rw-rw-r-- 1 dan 5000 0 2011-06-02 20:31 picture.txt

Notice that group has rw permission on the newly created files (touch and Nautilus respect umask setting).

2. Open the image file in Eye of Gnome.
$ eog picture.jpg
Rotate the image, Save the image. Close eog.

3. The file permissions have changed, group permissions are gone, and the permission do not match those of newly created files from other Gnome apps such as Nautilus.

$ ls -al picture*
-rw-rw-r-- 1 dan 5000 0 2011-06-02 20:37 picture.empty
-rw------- 1 dan 5000 1395718 2011-06-02 20:43 picture.jpg
-rw-rw-r-- 1 dan 5000 0 2011-06-02 20:31 picture.txt

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: eog 2.30.0-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-31.61-generic 2.6.32.32+drm33.14
Uname: Linux 2.6.32-31-generic x86_64
Architecture: amd64
Date: Thu Jun 2 20:06:12 2011
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: eog

Description of problem:
When saving an image, eog does not retain the original permissions and ownership.

Version-Release number of selected component (if applicable):
eog-2.24.3.1-1.fc10.i386

How reproducible:
Do a modification to an image in eog and save it.

Steps to Reproduce:
1. Open image in eog
2. Rotate the image
3. Save the image (File->Save)

Actual results:
The original permissions are gone.

Expected results:
The permissions should be retained.

Additional info:

This is painful for multi-user system or file server because it blocks other users from accessing the file.

In my case the original file attributes looked like this:

rw-rw-r--+ 1 myuser mygroup

After eog saved the image (in place) the attributes changed to:

rw-rw-r--+ 1 myuser myuser

My umask (when run in terminal) is 0002.

It seems this is caused by the way how eog performs the modification and save; strace output releals the following:

[pid 8643] lstat64("/tmp/eog-save-F87BWU", {st_mode=S_IFREG|0600, st_size=42043
7, ...}) = 0
[pid 8643] lstat64("/var/tmp/bio.jpg", {st_mode=S_IFREG|0664, st_size=409310, .
..}) = 0
[pid 8643] rename("/tmp/eog-save-F87BWU", "/var/tmp/bio.jpg" <unfinished ...>
[pid 8638] <... poll resumed> ) = 1 ([{fd=15, revents=POLLIN}])

Created attachment 349670
strace output of eog process which rotates and than saves an image

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Dan Stoner (danstoner) wrote :

Thank you for your bug report. I can confirm that on Ubuntu 11.04 (eog 2.32.1) eog changes the permissions to -rw------- after rotation (default umask). This is indeed odd… There has been a similiar report for Fedora 10 (I'm linking it just for completeness) which did never get any response and was closed automatically.
This issue seems to be an upstream one, it would be great if you submit in in the Gnome bug tracker: https://wiki.ubuntu.com/Bugs/Upstream/GNOME
Thanks in advance!

Changed in eog (Ubuntu):
status: New → Confirmed
Sebastien Bacher (seb128) wrote :
Changed in eog (Ubuntu):
importance: Undecided → Low
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eog - 3.2.2-2ubuntu2

---------------
eog (3.2.2-2ubuntu2) precise; urgency=low

  * debian/patches/git_correct_units.patch:
    - git patch to use the correct units for file stats
  * debian/patches/git_dont_change_permission_on_edit.patch:
    - git patch to preserve the permissions on images edition (lp: #792145)
 -- Sebastien Bacher <email address hidden> Fri, 02 Dec 2011 17:17:25 +0100

Changed in eog (Ubuntu):
status: Confirmed → Fix Released
Changed in eog:
importance: Unknown → High
status: Unknown → Fix Released
Chrescht (sekateur) wrote :

This is also broken in earlier versions..e.g. in Ubuntu Lucid with eog 2.32.0.
Should I open a new bug for Lucid?

Changed in eog (Fedora):
importance: Unknown → High
status: Unknown → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.