Thunar overrides the user's umask

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.

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.

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.

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

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

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.

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.

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).

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.

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.

... 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).

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.