I've been reading up on the "sticky bit" and it's _almost_ what i want… but not quite. ## Background I'm managing a small JupyterHub instance with three courses and an instructor for each course. I'd like to have a folder on the server for file submissions. Students (in the jupyterhub-users group) should be able to place their own files in the folder, but should not be able to move or view other files in the folder. Ideally, they should retain the ability to move or edit their own file. Course instructors (in the jupyterhub-instructors group) should have full access to files and folders in the submissions folder so they can move their students submissions around as they see fit. ## My current understanding I'm aware of the sticky bit… my problem with it is that it leaves the other instructors unable to modify the contents of the folder. Is there a version of the sticky bit that allows the _group_ to edit the folder? In that case, I can set ACLs such that jupyterhub-users have rwx permissions on the folder (allowing them to submit files to the folder and see the contents of it) and set the folder owner to root:jupyterhub-instructors so the instructors can control the contents of the folder. If all else fails, I suppose I can make subfolders in the submissions folder owned by each instructor, then set the sticky bit on each subfolder. I'd like to avoid the future maintenance associate with that though, since _I'll_ have to be the one to remember to set up a new folder next semester for each instructor.

**Is there any documentation for the default permissions of the /tmp folder on \*nix, in particular Linux?\ (Or perhaps /tmp doesn't have specified default permissions?)** Background:\ I'm trying to ensure temporary files I store inside of /tmp are secured. In particular I'd like a guarantee that the sticky bit (aka restricted deletion flag) is set on /tmp, so that the files cannot be deleted or renamed by anyone except the file owner. Searching around the web, it seems the sticky bit is likely set, e.g. - https://www.thegeeksearch.com/what-is-the-correct-permission-for-tmp-directory-in-linux/ - https://en.wikipedia.org/wiki/Sticky_bit However, I'd like to have "official" documentation confirming it one way or the other for the desktops my program may run on (which are Linux (most likely distros are Ubuntu and Debian) and macOS). This is so that I can be sure it's treated like a contract, and able to rely on it being set. The wording I find is typically more suggestive, along the lines of "typically the sticky bit is applied to /tmp". The most official documentations I've found are the below two: - [Linux man page for chmod](https://man7.org/linux/man-pages/man1/chmod.1.html#RESTRICTED_DELETION_FLAG_OR_STICKY_BIT) : "the restricted deletion flag [...] is commonly found on world-writable directories like /tmp" Which is suggestive of it being set, whereas I'd like a statement confirming it. - [An answer in Red Hat's Customer portal](https://access.redhat.com/solutions/49267) : "The /tmp directory requires special permissions. This directory has Sticky Bit permissions." This is the only mention I've found where it confirms /tmp has the sticky bit set (albeit on Red Hat). But it is not their [official documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/) , so it doesn't give me fully the same confidence as a specification in their documentation would (which I would treat as a contract they will uphold).

As shown below, on my Ubuntu system, carlo directory has the sticky bit permission set. It contains the file file1 owned by user lab.

-shellsession
lab@ubuntu:~$ ll | grep carlo
drwxrwxr-t  2 ubuntu ubuntu  4096 Oct 31 08:09 carlo/

lab@ubuntu:~$ ll /home/ubuntu/carlo/file1 
-rw-rw-r-- 1 lab ubuntu 0 Oct 31 08:09 /home/ubuntu/carlo/file1
lab@ubuntu:~$

As you can see user lab owns file1, yet he can't rename or delete the file.

-shellsession
lab@ubuntu:~$ mv /home/ubuntu/carlo/file1 /home/ubuntu/carlo/file2
mv: cannot move '/home/ubuntu/carlo/file1' to '/home/ubuntu/carlo/file2': Permission denied

lab@ubuntu:~$ rm /home/ubuntu/carlo/file1
rm: cannot remove '/home/ubuntu/carlo/file1': Permission denied
lab@ubuntu:~$

Is this an expected behavior?

I have structure like:

/home/reed/, user=reed, group=reed
  - apache-conf, user=reed, group=reed
  - apache-web, user=reed, group=apache, perm=0770
      - www.website.com, user=reed, group=apache, perm=0770
          - index.php, user=reed, group=apache, perm=0660

I'm using umask 007 in /etc/profile so my directories & files are created with these same permissions. & that worked. I ran chmod g+s /home/reed/apache-web; and chmod g+s /home/reed/apache-web/www.website.com so new directories will keep the group=apache So I mkdir /home/reed/apache-web/test/, then ls -la ... & it shows reed is both the user & the group. I tried using chmod 4770 /home/reed/apache-web/test/, but mkdir still sets both user & group to reed (or root if I'm running with sudo) I tried it in the www.website.com dir as well with the same results. I'm on Debian 10 with root access available. I also tried switching to user=apache & group=reed, then using chmod u+s thedir, but again, mkdir makes both the user & the group the current shell user. I also tried logging out & logging back in

I'm carrying out a one-off configuration operation which requires a remote client to communicate with a remote server. The client runs Apache, which runs a configure binary, which fetches various scripts from the server with curl. The returned scripts must be run by root. On the client configure is C++ code, and the binary is setuid root (no lectures please, unless you've got a better idea): $ ll /var/www1/cgi-bin/configure -rwsr-xr-x 1 root root 76160 Jul 13 19:20 /var/www1/cgi-bin/configure* The configure code creates a randomly-named directory in /tmp with mkdtemp : # ls -ld /tmp/vs_MYSosq drwx------ 2 root www-data 4096 Jul 13 20:29 /tmp/vs_MYSosq # ll /tmp/vs_MYSosq total 8 drwx------ 2 root www-data 4096 Jul 13 20:29 ./ drwxrwxrwt 25 root root 4096 Jul 13 20:29 ../ The code then execs curl, which retrieves the scripts, but then fails to write them to this directory (it exits with code 23). Any idea why curl can't write to this directory? Is this fixable or do I have to move out of /tmp (which is preferred because it's a ramdisk)? It's presumably a sticky-bit issue, but I can't see how, since the directory is empty and curl isn't attempting to over-write anything.

My task was to configure a directory so that users in a group could only delete files they own. I used

1771 RandD

, as suggested by lab instructions, to accomplish this. When running

-l

, the permissions were displayed as

--t

. I understand why there is a

at the end of the permissions, since the last 1 in

1771 RandD

is responsible for other permissions. However, what is the point of the first 1 if

is not displayed in the user's permissions section?

I try to set for NEW created files/directories in /home/test: 1) group to "test" 2) right to "770" This works for the group (1). chown :test /home/test chmod g+s /home/test But I do not get it for the rights (2). I want to set this behaviour to the directory /home/test and not to a user-setting (umask).

I've always heard that sticky bit should be only used with directories, and I understand that, but what is the meaning if it is applied to a file. If I set the sticky bit to a file and do an ls -la I see a capital T, but I don't know if this influences the behaviour of the file.

I have a directory test with the owner user:group and 770 as permissions. I want, that every directory and file within test do have the same specifications. I tried chmod g+s,u+s test, which partially worked: directories within that folder do inherit the ownership and permissions, but files only the owners, not the permissions. I also tried chmod g+t test, which was a total failure. How can i achieve the desired result? Edit: the administrator does not allow to install ACL and umask does dont work, since the files won't be generates from a CLI

### This doesn't work

find / -type d -perm 1000

The problem is, that it matches only the **exact** permission (1000), but I only want to *find* out if the sticky bit is set or not. I don't care about the other permissions... ### My solution so far I feel that there must be a better way than this:

find / -type d -perm 1001 -or -perm 1002 -or -perm 1003 -or -perm 1004 -or -perm 1005 -or -perm 1006 -or -perm 1007 -or -perm 1010 -or -perm 1011 -or -perm 1012 -or -perm 1013 -or -perm 1014 -or -perm 1015 -or -perm 1016 -or -perm 1017 -or -perm 1020 -or -perm 1021 -or -perm 1022 -or -perm 1023 -or -perm 1024 -or -perm 1025 -or -perm 1026 -or -perm 1027 -or -perm 1030 -or -perm 1031 -or -perm 1032 -or -perm 1033 -or -perm 1034 -or -perm 1035 -or -perm 1036 -or -perm 1037 -or -perm 1040 -or -perm 1041 -or -perm 1042 -or -perm 1043 -or -perm 1044 -or -perm 1045 -or -perm 1046 -or -perm 1047 -or -perm 1050 -or -perm 1051 -or -perm 1052 -or -perm 1053 -or -perm 1054 -or -perm 1055 -or -perm 1056 -or -perm 1057 -or -perm 1060 -or -perm 1061 -or -perm 1062 -or -perm 1063 -or -perm 1064 -or -perm 1065 -or -perm 1066 -or -perm 1067 -or -perm 1070 -or -perm 1071 -or -perm 1072 -or -perm 1073 -or -perm 1074 -or -perm 1075 -or -perm 1076 -or -perm 1077 -or -perm 1101 -or -perm 1102 -or -perm 1103 -or -perm 1104 -or -perm 1105 -or -perm 1106 -or -perm 1107 -or -perm 1110 -or -perm 1111 -or -perm 1112 -or -perm 1113 -or -perm 1114 -or -perm 1115 -or -perm 1116 -or -perm 1117 -or -perm 1120 -or -perm 1121 -or -perm 1122 -or -perm 1123 -or -perm 1124 -or -perm 1125 -or -perm 1126 -or -perm 1127 -or -perm 1130 -or -perm 1131 -or -perm 1132 -or -perm 1133 -or -perm 1134 -or -perm 1135 -or -perm 1136 -or -perm 1137 -or -perm 1140 -or -perm 1141 -or -perm 1142 -or -perm 1143 -or -perm 1144 -or -perm 1145 -or -perm 1146 -or -perm 1247 -or -perm 1350 -or -perm 1351 -or -perm 1352 -or -perm 1453 -or -perm 1454 -or -perm 1555 -or -perm 1556 -or -perm 1657 -or -perm 1660 -or -perm 1661 -or -perm 1662 -or -perm 1663 -or -perm 1764 -or -perm 1765 -or -perm 1766 -or -perm 1767 -or -perm 1770 -or -perm 1771 -or -perm 1772 -or -perm 1773 -or -perm 1774 -or -perm 1775 -or -perm 1776 -or -perm 1777

Anyone know why rocky can't write to /tmp/afile? Giving rocky permission as an other user with chmod o+w doesn't seem to work either 🤔 I updated the acl with: setfacl -m u:rocky:rw /tmp/afile id as rocky and owner: > rocky@jammy:~$ id > uid=1001(rocky) gid=1001(rocky) groups=1001(rocky) > seb@jammy:~$ id > uid=1000(seb) gid=1000(seb) groups=1000(seb),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),134(lxd),135(sambashare) ls -ld output > seb@jammy:~$ ls -ld /tmp/afile > -rw-rw-rw-+ 1 seb seb 0 Jul 3 14:25 /tmp/afile Owner is able to write without issue: > seb@jammy:~$ echo rounders > /tmp/afile > seb@jammy:~$ cat /tmp/afile > rounders getfacl -n output: > seb@jammy:~$ getfacl -n /tmp/afile getfacl: Removing leading '/' from > absolute path names > # file: tmp/afile > # owner: 1000 > # group: 1000 > user::rw- > user:1001:rw- > group::rw- > mask::rw- > other::rw- df -T and mount output: > seb@jammy:~$ df -T /tmp > Filesystem Type 1K-blocks Used Available Use% Mounted on > /dev/sda2 ext4 120044288 18487840 95412296 17% / > seb@jammy:~$ mount | grep /dev/sda2 > /dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro) > /dev/sda2 on /var/snap/firefox/common/host-hunspell type ext4 (ro,noexec,noatime,errors=remount-ro) Attempt to write to file as rocky: seb@jammy:~$ getfacl /tmp/afile getfacl: Removing leading '/' from absolute path names # file: tmp/afile # owner: seb # group: seb user::rw- user:rocky:rw- group::rw- mask::rw- other::rw- seb@jammy:~$ su - rocky #Password: rocky@jammy:~$ echo hello > /tmp/afile -bash: /tmp/afile: Permission denied

I experience a strange behaviour in stick bit on /tmp directory and flock command. Tried with two cases: Case 1: create file with Ubuntu user, root have no access to the created file. ubuntu@:~$ touch -a /tmp/ubuntu_user_created.lck ubuntu@:~$ flock -n /tmp/ubuntu_user_created.lck -c "echo 123" 123 ubuntu@:~$ sudo flock -n /tmp/ubuntu_user_created.lck -c "echo 123" flock: cannot open lock file /tmp/ubuntu_user_created.lck: Permission denied Case 2: create file with root user, root and Ubuntu user have access to the created file. ubuntu@:~$ sudo touch -a /tmp/root_user_created.lck ubuntu@:~$ flock -n /tmp/root_user_created.lck -c "echo 123" 123 ubuntu@:~$ sudo flock -n /tmp/root_user_created.lck -c "echo 123" 123 Permission in the two files: ls -la /tmp/ total 52 drwxrwxrwt 12 root root 4096 Oct 6 08:08 . drwxr-xr-x 19 root root 4096 Oct 6 03:42 .. -rw-r--r-- 1 root root 0 Oct 6 07:56 root_user_created.lck -rw-rw-r-- 1 ubuntu ubuntu 0 Oct 6 07:54 ubuntu_user_created.lck I don't understand why Ubuntu user can run the command flock -n /tmp/root_user_created.lck successfully, since the file root_user_created.lck is owned by root, does the flock command just want to open this file with read mode? If the flock command only need a read access, so why run the command flock -n /tmp/ubuntu_user_created.lck command with root privileges return permission denied?

Using the following rsync command, the RWX permissions are being correctly set for both files and directories but the sticky bit options are not. rsync -rtvz --partial-dir=.rsync-partial --chmod=Da+t,Dg+s,D770,F0740 --progress --stats -e 'ssh -p 19419' "/home/me/test_dir" me@REMOTE_HOST:~ I understand that the options should act as below: Da+t - all dirs should have sticky bit set (only the root user, the owner of the directory, and the owner of a file can remove files within said directory.) Dg+s - all dirs should have setGID (all files created within said directory inherit the group ownership of that directory) but sticky bits and setGID bits are not set on the REMOTE_HOST dirs with the above command. If I ssh to the REMOTE_HOST and run something like chmod -R a+t test_dir then the sticky bits will be set as expected. Where am I going wrong? Edit: I also separately tried just "--chmod=Da+t,Dg+s", "--chmod=Da+t" "--chmod=Dg+s" "--chmod=a+t" and no sticky bits are set with any of these options. (Ubuntu 16.04, rsync 3.1.1 - I took the chmod options straight from the man page)

In various places one can see the "sticky bit" accused of nowadays being a complete misnomer, as its functionality _nowadays_ is to affect the write permissions on directories and act as a _restricted deletion_ flag. In an AskUbuntu answer the answerer wrote that ["a sticky bit usually applies to directories"](https://askubuntu.com/a/789948/43344) . I observed that indeed modern systems seem in practice to never apply it to files, but that a long time ago the _usual_ case was for it to apply to (executable program image) files rather than to directories. (When it comes to the paucity of modern usage on files, there's a related question at https://unix.stackexchange.com/questions/23757/ .) This prompted the question: > [What _did_ a sticky bit applied to an executable do? Was it like setuid then?](https://askubuntu.com/questions/789938/why-do-mount-ping-and-su-have-a-sticky-bit-set/789948#comment1187830_789948) Note the past tense. This is not https://unix.stackexchange.com/questions/79395/ now. It's how it used to work then.

Consider the following setup: # two users in groups sales useradd edwin useradd santos groupadd sales usermod -aG sales edwin usermod -aG sales santos # two users in group account useradd serene useradd alex groupadd account usermod -aG account serene usermod -aG account alex # every group has its own directory with full access mkdir -p ./groups/sales ./groups/account cd ./groups chown :account ./account chown :sales ./sales chmod g+rwx ./account ./sales The task states: > Users have permissions to delete only their own files, but alex is the general manager, so user alex has access to delete all users' files. Now users should be able to only delete their own files, so I do: chmod +t /groups/account /groups/sales But now I have a problem. Alex is admin, and should be able to delete _anyone's_(!) files. So I do for example: setfactl -a u:alex:rwx /groups/sales /groups/account But this does not help: [root@localhost groups]# getfacl sales/ # file: sales/ # owner: root # group: sales # flags: --t user::rwx user:alex:rwx group::rwx mask::rwx other::r-x [root@localhost groups]# sudo -u edwin touch sales/file [root@localhost groups]# sudo -u alex rm -f sales/file rm: cannot remove 'sales/file': Operation not permitted Is it possible to apply sticky flag to all except one user?

I installed a fresh ubuntu with apache2. I created a new folder "/var/www/foobar" with the following user:group -> black www-data. I need new files created inside this folder to inherit the user and group of that folder. So I executed chmod g+s /var/www/foobar drwxr-xr-t 2 black www-data 4,0K Okt 9 10:12 foobar ---------- But if I create a new file inside this folder, then the user and group is set to black black instead of black www-data. I also tried to add the user to the group www-data with sudo usermod -a -G www-data black but it made no difference. What am I missing?

The way I understand the sticky bit on directories is that only the owner of a file within that directory can delete the file, instead of everybody with write permission. I don't get, though, where that would be actually useful. If everybody can still edit my file, including just deleting all the contents, what scenario is there where the sticky bit actually helps? I have read that it is used on /tmp, I don't get why that is either.

I'm prepping for the LPIC1 exam, strongly relying on their online material here . Can someone pls help me clarify this doubt? What is the difference among these: 1.

find ~ -perm 4000

2.

find ~ -perm -4000

3.

find ~ -perm /4000

sudoedit does not allow editing files when the original user has write access to one of the parent directories (as explained [here](https://unix.stackexchange.com/questions/356142/sudoedit-root-owned-file-in-a-non-root-directory/356145#356145)) . However, I'm noticing that sudoedit does not seem to take into account the sticky bit when performing this check. For example, I have /tmp with mode 1777 owned by root:root, and /tmp/foo also owned by root:root. Since /tmp has the sticky bit set, I think I should be able to use sudoedit on /tmp/foo, but I can't:

$ sudoedit /tmp/foo
sudoedit: /tmp/foo: editing files in a writable directory is not permitted

Shouldn't sudoedit be able to notice the sticky bit and not consider /tmp to be writable for the purposes of this check? Or would doing so introduce some security issue I'm not aware of?

Is it possible to remove access of /tmp directory for a particular user, i.e user should not be able to even read /tmp directory ? I know tmp directory has 1777 permission and let every user to create files , but restrict modification to user's own files. I am unable to find any way to do so. Usecase: One set of users should be able to do whatever they want but other set of user should not be able to check what other set of users are creating. One solution is to create a directory and set permission to allow only set of users, but then all users need to edit there script/program to use this particular directory instead. Is there any way like privatetmp via systemd, but for users instead of service ? I mean setup a tmp directory for the user without user knowing about it, is it possible ?