116

I have created a really really short life temporary directory that I wanted to share between some users for a few hours : /some/path/tmp

Unfortunately I have launched sudo chown 777 -R /tmp instead of sudo chown 777 -R tmp, so my /tmp file is now completely public.

Is it a security concern now that it is completely set to public? Should I change it back to more secure settings? What are the correct permissions for /tmp?

  • Beware that I forgot something important in my initial answer: the X11 socket needs to be publicly accessible, otherwise you won't be able to start new GUI applications. I've updated my answer. – Gilles 'SO- stop being evil' Apr 08 '13 at 09:36
  • Was it chown or chmod? – Melebius Jul 26 '18 at 20:29
  • @Melebius I am a bit puzzled by your question: I did not mention chmod. chown (like ch - own), is about ownership of files, which user owns a file. chmod (like ch - modifify) is more about who can execute, or write inside, or read the content of a file. – Stephane Rolland Jul 29 '18 at 08:17
  • 3
    @StephaneRolland Yes, that’s what confused me. You can use chown 777 which sets the ownership of a file to the user with the ID 777. However, all the answers, including the accepted one, work with chmod. Since all of them set the permission to the same value for all the users (owner, group, others), most effects of the file ownership become irrelevant. However, the correct command to rectify the result of sudo chown 777 -R /tmp should be sudo chown root -R /tmp. – Melebius Jul 29 '18 at 13:04

3 Answers3

169

The normal settings for /tmp are 1777, which ls shows as drwxrwxrwt. That is: wide open, except that only the owner of a file can remove it (that's what this extra t bit means for a directory).

The problem with a /tmp with mode 777 is that another user could remove a file that you've created and substitute the content of their choice.

If your /tmp is a tmpfs filesystem, a reboot will restore everything. Otherwise, run chmod 1777 /tmp.

Additionally, a lot of files in /tmp need to be private. However, at least one directory critically needs to be world-readable: /tmp/.X11-unix, and possibly some other similar directories (/tmp/.XIM-unix, etc.). The following command should mostly set things right:

chmod 1777 /tmp
find /tmp \
     -mindepth 1 \
     -name '.*-unix' -exec chmod 1777 {} + -prune -o \
     -exec chmod go-rwx {} +

I.e. make all files and directories private (remove all permissions for group and other), but make the X11 sockets accessible to all. Access control on these sockets is enforced by the server, not by the file permissions. There may be other sockets that need to be publicly available. Run find /tmp -type s -user 0 to discover root-owned sockets which you may need to make world-accessible. There may be sockets owned by other system users as well (e.g. to communicate with a system bus); explore with find /tmp -type s ! -user $UID (where $UID is your user ID).

  • 1
    could you explain the second chmod more? – Bartlomiej Lewandowski Apr 08 '13 at 08:38
  • @BartlomiejLewandowski go-rwx: no permissions for group and others. This sets the permissions to rwx------ (except that files that were created since the chmod may end up with fewer permissions, e.g. rw-------). In other words, the files will be accessible only by their owner. /tmp/.[!.]* is to include dot files, which commonly exist in /tmp. – Gilles 'SO- stop being evil' Apr 08 '13 at 09:28
  • @BartlomiejLewandowski: chmod -go-rwx : set "rwx" rights to Owner and Group. r=read, w=write, x=execute(for file) or enter/traverse(for directory). 777 = rwxrwxrwx (the right part can be seen as : "set 'r' set 'w' set 'x', set 'r' set 'w' set 'x', set 'r' set 'w' set 'x'" , which in binary is represented as "111111111" (1 to set, 0 to unset) . And "111111111" in binary is represented in octal as "777" (octal = groups of 3 bits, each group having value 0 to 7). if "rwxr-xr--" it would be "111101100" which in octal is "754" – Olivier Dulac Apr 08 '13 at 11:12
  • 4
    The +t is referred to as the sticky bit. That's what keep anyone other than the owner from being able to remove files, even though the permissions are 777 otherwise. The sticky bit was originally to get the kernel to leave commonly programs in memory when they exited so they wouldn't have to be fetched from disk when next run. We're talking PDP11 days.... – kurtm Oct 08 '13 at 21:51
  • I'm running chmod -R go-rwx /tmp/* /tmp/.[!.]* on Ubuntu 16.04 and getting an error: -bash: /usr/bin/sudo: Argument list too long – Gabriel Fair Apr 20 '18 at 10:43
  • 1
    @GabrielFair I replaced the command using wildcards by one using find which won't run into that problem. – Gilles 'SO- stop being evil' Apr 21 '18 at 08:58
  • wouldnt this be enough? (if you are able to reboot the server) chmod 1777 /tmp; reboot – rubo77 Apr 12 '20 at 04:18
  • also check /var/tmp the same way, maybe you have the same error there – rubo77 Apr 12 '20 at 04:26
  • Should I also do chmod 1777 -R /tmp for reaching out to subfolders I have created? – alper Jul 28 '20 at 02:42
  • 1
    @alper No, do not do that. 1777 is for /tmp itself, which is writable by everybody. Almost all directories in /tmp should only be readable and writable by their owner. – Gilles 'SO- stop being evil' Jul 28 '20 at 07:06
  • @Gilles'SO-stopbeingevil' "If your /tmp is a tmpfs filesystem, a reboot will restore everything. *Otherwise, run chmod 1777 /tmp." Two question arise: 1. how to know whether /tmp is tmpfs filesystem or not? 2. what do you want to tell us by "Otherwise, run chmod 1777 /tmp"*, could you please explain that in more detail for me? – John Sep 27 '21 at 04:58
  • @John To see if /tmp is a tmpfs filesystem, run df /tmp and see whether it's something like /dev/… … … … … / (part of the root filesystem) or tmpfs … … … … /tmp (a separate tmpfs filesystem). As for chmod 1777 /tmp, not sure what to add. It's the command to set /tmp to the permissions it should have. – Gilles 'SO- stop being evil' Sep 27 '21 at 08:01
  • @Gilles'SO-stopbeingevil' Why should invoke run chmod 1777 /tmp when /tmp is not tmpfs filesystem? – John Sep 27 '21 at 08:03
  • @John This is an answer to the question “What are correct permissions for /tmp ?” – Gilles 'SO- stop being evil' Sep 27 '21 at 08:06
17

/tmp and /var/tmp should have read, write and execute rights for all; but you'd usually would also add the sticky-bit (o+t), to prevent users from removing files/directories belonging to other users. So chmod a=rwx,o+t /tmp should work.

As for changing permissions recursively... As long as the owner/group remains as it is for the files and directories, it shouldn't be that much of a problem. But you could perhaps change the permission of everything under /tmp (not /tmp itself) to ensure users' privacy, by removing the rx rights of others and perhaps the group.

Find is a good way of doing this. As root, do:

cd /tmp
find . -type f -exec chmod u=rw,go= {} \;   # (or u=rw,g=r,o= {})
find . -type d -exec chmod u=rwx,go= {} \;  # (or u=rwx,g=rx,o= {})
3
[root@Niflheim tmp]# ls -alF .
total 1632
drwxrwxrwt 15 root root    4096 Apr  7 04:24 ./
drwxr-xr-x 28 root root    4096 Apr  2 21:02 ../
[root@Niflheim tmp]# stat -c '%A %a %n' .
drwxrwxrwt 1777 .

From a CentOS 5.9 machine.