Thunar overrides the user's umask

Bug #242842 reported by Craig Ringer
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Thunar File Manager
In Progress
Unknown
thunar (Ubuntu)
Fix Released
Low
Lionel Le Folgoc
Jaunty
Won't Fix
Low
Unassigned
Karmic
Fix Released
Low
Lionel Le Folgoc

Bug Description

Binary package hint: thunar

Thunar overrides user's umask when creating files and directories. For example, if my session-wide umask is 0002, as set by:

<pre>
/etc/X11/Xsession.d/98umask:
--------
#!/bin/bash
umask 0002
--------
</pre>

Thunar still creates directories (right-click menu, create folder) with mode 0755 and files (right-click menu, create file, empty file) with mode 0644. This is incorrect behavior; the directory and file should be created with 0775 and 0664 respectively if the user's umask is 0002.

This causes major problems for shared sites, such as those using LTSP (for which Thunar is otherwise ideally suited), because users working in shared directories cannot work with each others' files. Thunar does not know what the user wants better than the user and the site admin do, and shouldn't pretend it does.

Thunar is: thunar 0.9.0-4ubuntu2 from Hardy (8.10)

Related branches

Revision history for this message
Craig Ringer (ringerc) wrote :

Expected, as illustrated by the shell's behaviour:

craig:~$ mkdir test
craig:~$ touch test/testf
craig:~$ find test -ls
3227979 4 drwxrwxr-x 2 craig users 4096 Jun 25 15:12 test
3227984 0 -rw-rw-r-- 1 craig users 0 Jun 25 15:12 test/testf

Actual results from Thunar:

craig:~$ find thunartest/ -ls
3228002 4 drwxr-xr-x 2 craig users 4096 Jun 25 15:14 thunartest/
3228003 0 -rw-r--r-- 1 craig users 0 Jun 25 15:14 thunartest/thunartestfile

Results after patch:

craig:~$ find thunartest/ -ls
3228002 4 drwxrwxr-x 2 craig users 4096 Jun 25 15:14 thunartest2/
3228003 0 -rw-rw-r-- 1 craig users 0 Jun 25 15:14 thunartest2/thunartestfile2

Patch attached.

Revision history for this message
Craig Ringer (ringerc) wrote :

Someone who knows Thunar well should check this and make sure these code paths aren't also used for anything that might care about group/world write if the user's umask permits it. To me it looks pretty safe, though.

Revision history for this message
Craig Ringer (ringerc) wrote :

Someone who knows Thunar well should check this and make sure these code paths aren't also used for anything that might care about group/world write if the user's umask permits it. To me it looks pretty safe, though.

Changed in thunar:
status: Unknown → In Progress
Changed in thunar:
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Lionel Le Folgoc (mrpouit) wrote :

Fixed upstream (http://svn.xfce.org/index.cgi/xfce?view=revision&revision=29654), I'll upload a new revision with this patch soon.

Changed in thunar:
assignee: nobody → mrpouit
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunar - 1.0.0-1ubuntu2

---------------
thunar (1.0.0-1ubuntu2) jaunty; urgency=low

  * debian/patches/03_thunar-vfs-apply-umask-properly.patch: correctly honor
    user's umask (LP: #242842).
  * Resync packaging files with pkg-xfce (r2934):
    - debian/patches: refresh 02_thunar-icon-naming-spec-compliance, more
      replacement.

 -- Lionel Le Folgoc <email address hidden> Fri, 13 Mar 2009 23:13:17 +0100

Changed in thunar:
status: In Progress → Fix Released
Revision history for this message
Michael Nagel (nailor) wrote :

i am running up to date jaunty (thunar 1.0.0-1ubuntu3)

and doing the following:
1) log in
2) right click -> open terminal here
3) execute "umask" --> 022
4) close terminal
5) right click -> create folder -> ok
6) right click -> open terminal here
7) execute "umask" --> 000

tried many times. reproducible. bad.

Changed in thunar (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Craig Ringer (ringerc) wrote :

Michael: That test is invalid, and shows nothing. You've misunderstood how the umask works.

In a UNIX system, things like environment variables, ulimit settings and the umask are inherited from the parent process during process creation.

Your test has a process tree like this:

Thunar
    terminal
        bash

and you're changing the umask in the 'bash' process that you then terminate by closing the terminal. Nothing else has changed. (Technically the terminal process is probably a peer of Thunar rather than a child, despite having been created by Thunar, because Thunar detaches from it to avoid killing it if Thunar dies or is restarted - but that doesn't really matter for the purposes of this discussion).

Additionally, you're trying to test by setting the umask then checking it again later. This fails to detect the case where Thunar isn't changing the umask, but rather overriding it in individual mkdir(...) etc system calls. Which is what it was doing, by the way, before this bug was fixed - it wasn't setting the umask, but rather was ignoring it and specifying its own mask for file and directory operations.

A valid test would be to launch a terminal, kill Thunar, set your umask, then re-launch Thunar from within that terminal session, then create a directory using that Thunar process and see if it's permissions (shown using 'ls -l') are appropriate for the umask you set.

Better, set your umask globally using PAM options, /etc/profile, or (preferably) a new file in /etc/X11/XSession.d for the purpose. Be aware that if you set your umask in /etc/profile or by PAM it might get overridden by your X session startup scripts in some distros. That's *NOT* to do with Thunar.

Changed in thunar (Ubuntu):
status: Confirmed → Fix Released
status: Fix Released → Fix Committed
Revision history for this message
Lionel Le Folgoc (mrpouit) wrote :

I've no time to check in detail now, but the patch shipped in our jaunty package is probably incomplete, and should be replaced by the one shipped in karmic (http://git.xfce.org/xfce/thunar/commit/?h=xfce-4.6&id=eb58c6a6ba7f77c2c16016db064524df598ef421).

Changed in thunar (Ubuntu Karmic):
status: New → Fix Released
importance: Undecided → Low
assignee: nobody → Lionel Le Folgoc (mrpouit)
Changed in thunar (Ubuntu):
status: Fix Committed → Fix Released
Changed in thunar (Ubuntu Jaunty):
status: New → Incomplete
importance: Undecided → Low
Revision history for this message
Michael Nagel (nailor) wrote :

Craig, you are right that my problem most certainly is not a duplicate of the bug discussed here, but a separate problem.

Even though it might be totally unrelated to your problem, I do not think my test is invalid in general, because it results in world-writable files that most certainly are not intended. It should thus probably be moved to a separate thread.

The thing I wanted to demonstrate is:
- after loggin in the umask is set to 022 because it is set to 022 in /etc/profile and not changed somewhere else. my somewhat incompetent way of determining this is to open a terminal and run umask.
- then i open my home folder in thunar and create a new folder using the right-click menu. i think thunar is responsible for creating the directory at this point, but i might be mistaken because i am a gnome user usually.

and from that point on the problem is:
1) when creating further folder/files using right-click-menu they are created world-writable
2) when trying to determine my umask as described above, i find it is 000 now

1) this is a bug. even if my theory about the umask is complete nonesense, this is a obvious, serious, plain bug.
2) i do not know how bad my method of determining the umask is, but i think the reason that i get 000 there is that it actually is 000 and bash (zsh to be precise) inherited it from xfce terminal that inherited it from thunar. and i dont know where thunar got it from, but that is what i postulate to be the underlying bug. this theory is supported by the observation that if i launch a gnome-terminal from the xfce terminal and run umask there i get 022 again, because this breaks the chain of inheritance somehow.

Revision history for this message
Craig Ringer (ringerc) wrote :

Michael:

Yep, that's ugly. It actually is properly associated with this bug, too, as the patch Debian and Ubuntu have for Thunar is completely borked.

The umask patch:
  http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/jaunty/thunar/jaunty/revision/58
is at fault for this. It calls:

   umask(0)

thus changing the user's umask (wtf?!?). It does so in a really bizarre way:

+ if (!_thunar_vfs_io_ops_mkdir (lp->data, 0777 & ~umask(0), THUNAR_VFS_IO_OPS_NONE, error))

... that makes me think that whoever wrote that completely fails to understand how the umask works and what it does. People seem to be unable to understand that *they* *don't* *have* *to* *mess* *with* *the* *umask*. It's a *mask* and is applied automatically by libc to mask out disallowed permissions bits, so the app just asks for the most general permissions that make sense (0666 for files, 0777 for dirs) unless it has a really good reason (like creating a file to contain a private key) not to.

My original patch for this issue works fine and gets this right. I have no idea why the above was used instead. Karmic carries a correct patch; the same patch just needs to be applied to Jaunty.

Changed in thunar (Ubuntu Jaunty):
status: Incomplete → Confirmed
Revision history for this message
Craig Ringer (ringerc) wrote :

... however, Jaunty isn't a LTS release and has been superceded by Karmic, so I don't know if anyone with the power to do so will/can actually merge the patch that corrects this:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/thunar/karmic/revision/61/debian/patches/04_fix-umask-handling.patch

If upgrading isn't an option, you can apt-get source thunar, apply the patch, and then `fakeroot debian/rules binary' to build new patches. (Oversimplified - see Google for instructions on manually patching Debian packages).

Revision history for this message
Charlie Kravetz (cjkgeek) wrote :

Thank you for reporting this bug to Xubuntu. Xubuntu 9.04(Jaunty) reached EOL on 2010-10-23.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

This bug was resolved in later versions of Xubuntu, however, it will not be fixed in Xubuntu 9.04.

Please feel free to report any other bugs you may find.

Changed in thunar (Ubuntu Jaunty):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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