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 507261 - umask settings ignored and other permissions issues
umask settings ignored and other permissions issues
Status: RESOLVED OBSOLETE
Product: file-roller
Classification: Applications
Component: general
2.20.x
Other Linux
: Normal normal
: ---
Assigned To: file-roller-maint
file-roller-maint
Depends on:
Blocks:
 
 
Reported: 2008-01-04 13:36 UTC by Josselin Mouette
Modified: 2020-11-11 19:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Josselin Mouette 2008-01-04 13:36:07 UTC
When creating directories in the extraction process, file-roller ignores the user’s umask settings, and this takes various forms. In the following cases the umask should be used, but instead:
 * When creating a directory upon user’s request (dlg-batch-add.c:202, dlg-extract.c:135, fr-window.c:5761), permissions are always 755.
 * When using the nautilus extension, the created directory (fr-archive.c:3295) is always 0700.
 * The file temporarily extracted when pasting data (fr-window.c:7096) is always 0700, but maybe it is safer for this one.

Furthermore, some permissions seem wrong in some cases:
 * When copying remote files to a local temporary directory (fr-archive.c:1980), the make_tree function is used and sets permissions to 0755, maybe this should be 0700 instead.
 * The temporary directory to pack a jar archive (fr-command-jar.c:103) is 0755, it should probably be 0700 instead as well.

Additionnally, there are functions to copy/move files in file-utils.c that always set permissions to 755, but these functions seem unused.

I can prepare a patch if you agree with the proposed changes (although I’m not 100% sure of the safe way to get the umask).
Comment 1 Samuel Lidén Borell 2008-05-15 18:29:25 UTC
Also, there's a problem when extracting tar files: file-roller passes the -p option to tar which causes it to ignore the umask. Is there a good reason for this? If the .tar file has been created on a system without U-G-O style permissions these might all be 0777 (world writable) which is usually not wanted and is insecure. 
Comment 2 Jonathan Greig 2014-10-30 13:00:58 UTC
I can confirm that this is indeed a bug. The severity of this bug should be at least Major, not Normal. Also the status should be updated from UNCONFIRMED to NEW. This bug effectively makes file-roller useless for extracting archives.

It is still present in version 3.10.2.1.
Every single directory in an extracted archive will always be 0700.
Please see the Embroidermodder GitHub Issue #59 ( https://github.com/Embroidermodder/Embroidermodder/issues/59 ) which confirms that it is still a problem. The diagnosis started when GitHub user essence-of-orange joined the conversation.
Comment 3 André Klapper 2020-11-11 19:14:17 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use file-roller and if you still see this bug / want this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/file-roller/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (volunteer workforce and time is limited).