Ubuntu
evince package

"Save Copy As" with file opened from Firefox results in restrictive permissions

Bug #1084820 reported by Joshua Lock on 2012-11-30

This bug affects 6 people

Affects		Status	Importance	Assigned to	Milestone
	Evince	Unknown	Wishlist	gnome-bugs #689319
	evince (Ubuntu)	Triaged	Low	Unassigned

Bug Description

A common usage pattern of mine is to download PDF's through Firefox by clicking the link and selecting "Open with", on occasion I'd like to keep the PDF's so use the File->Save a Copy As menu item in Evince to save a copy in my home directory.

The files are copied with the same permissions they have when downloaded by Firefox to tmp (r--------) - this leads to the protected badge icon being displayed over the file in Nautilus and a file which is less accessible (from a privileges perspective) than others created and saved to my home directory (with the default permissions of rw-rw-r--).

I think it would be good to remain consistent with the default permissions when effectively creating a new document rather than maintaining the more restrictive permissions of the temporary file.

Ubuntu Version info:
Description: Ubuntu 12.10
Release: 12.10

Evince Version info:
evince:
  Installed: 3.6.0-0ubuntu2
  Candidate: 3.6.0-0ubuntu2
  Version table:
*** 3.6.0-0ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages
        100 /var/lib/dpkg/status

Sebastien Bacher (seb128) on 2012-11-30

Changed in evince (Ubuntu):
status:	New → Triaged
importance:	Undecided → Low

Bug Watch Updater (bug-watch-updater) on 2012-11-30

Changed in evince:
importance:	Unknown → Wishlist
status:	Unknown → New

Revision history for this message

Joshua Lock (incandescant) wrote on 2012-11-30:

I don't think that this bug is in Evince itself. I've been taking a look at the code and found that in ev_xfer_uri_simple() libdocument/ev-file-helpers.c:419 the call to g_file_copy() passes G_FILE_COPY_TARGET_DEFAULT_PERMS

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/evince/quantal/view/head:/libdocument/ev-file-helpers.c#L419

which according to the glib docs "Leaves target file with default perms, instead of setting the source file perms."

Revision history for this message

Joshua Lock (incandescant) wrote on 2012-11-30:

Some debugging information.

The temp file opened by Firefox in Evince:

user@computer:/tmp
$ stat -c '%n %a %A' Some\ Pdf.pdf
Some\ Pdf.pdf 400 -r--------

The same file saved in my home directory using "Save a copy":

user@computer:~/Documents
$ stat -c '%n %a %A' Some\ Pdf.pdf
Some\ Pdf.pdf 400 -r--------

user@computer:~/Documents
$ umask
0002

The resulting file should be 664 though, right?

Revision history for this message

Joshua Lock (incandescant) wrote on 2012-11-30:

test-g-file-copy.c Edit (714 bytes, text/plain)

I just wrote a simple test program (attached) to try and replicate the code path where the file is copied and it results in a file with 664 permissions.

Seems the bug *is* in evince, but it's not a bug that upstream can replicate.

Bug Watch Updater (bug-watch-updater) on 2012-12-01

Changed in evince:
status:	New → Unknown

Revision history for this message

Sebastien Bacher (seb128) wrote on 2012-12-03:

yeah, I don't know, we don't patch evince's code so I'm not sure what is at play there... note that doing a "cp" from the command line ends up with the same permissions that the evince copy

Revision history for this message

Joshua Lock (incandescant) wrote on 2012-12-03:

Hmm, interesting. It's expected that cp would result in the same permissions as the tmp file. It's the G_FILE_COPY_TARGET_DEFAULT_PERMS flag which should set the permissions to the defaults for the destination directory.

I was wondering if the issue is in GLib but the test program mimics the GLib paths without replicating the bug.

I'm kind of stumped as to where to look next...

Revision history for this message

Tommy Trussell (tommy-trussell) wrote on 2015-04-01:

I am seeing this in Evince 3.10.3 after upgrading to Ubuntu 14.04. A Google search first sent me to Bug #1214874, which was marked as a duplicate of Bug #1096837 -- an AppArmor issue. THAT bug says it was fixed last August in evince version 3.10.3-0ubuntu15, but unfortunately that's a Utopic package, and Trusty has only been updated from 3.10.3-0ubuntu10 to 3.10.3-0ubuntu10.2 .

I gather this particular fix is not being backported to Ubuntu 14.04 LTS "Trusty"? Anyone willing to sponsor a SRU to get this fix into Trusty?