eog (Eye of Gnome) ignores umask settings
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Eye of GNOME |
Fix Released
|
High
|
|||
| eog (Fedora) |
Won't Fix
|
High
|
|||
| eog (Ubuntu) |
Fix Released
|
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
ProcVersionSign
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
Related branches
|
|
#6 |
|
|
#7 |
| Dan Stoner (danstoner) wrote | #1 |
| Marcel Stimberg (marcelstimberg) wrote | #2 |
| Changed in eog (Ubuntu): | |
| status: | New → Confirmed |
| Sebastien Bacher (seb128) wrote | #3 |
| Changed in eog (Ubuntu): | |
| importance: | Undecided → Low |
| Launchpad Janitor (janitor) wrote | #4 |
| Changed in eog (Ubuntu): | |
| status: | Confirmed → Fix Released |
| Changed in eog: | |
| importance: | Unknown → High |
| status: | Unknown → Fix Released |
| Chrescht (sekateur) wrote | #5 |
| Changed in eog (Fedora): | |
| importance: | Unknown → High |
| status: | Unknown → Won't Fix |
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.
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(
7, ...}) = 0
[pid 8643] lstat64(
..}) = 0
[pid 8643] rename(
[pid 8638] <... poll resumed> ) = 1 ([{fd=15, revents=POLLIN}])