Looking at the find command, it’s highly incorrect at what it’s supposed to do, at least when run on CentOS 7 with “find (GNU findutils) 4.5.11”
First: -perm -g-s is always true. g-s means “s bit not set”, but for the -perm search you need something set and not “not set”. So effectively the find command finds all directories, which in the end gets the job done anyway, even though with a huge overhead, in particular the directories don’t need to be changed again.
Correct would be -perm -g+s to find all directories, which have the group sticky bit set. As we want only those directories which have it missing, the condition must be negated. Thus the correct find command would be:
Second: the content directory contains a lot of directories and if all of them are missing the sticky bit it would make a chmod call for every directory which can take a looooong time.
In most cases + is what people actually want. Only commands that accept a single argument need \;.
Another thing I wonder about: why is only chmod run through sudo? It feels like the entire script should be ran as root. Why is there an overhead of using sudo for chmod?
Cool. Even better. Save a couple of letters and a few milliseconds.
I left the sudo out, too. Doesn’t make much sense to me to run this as any other user but root, in particular in case some part of the directory tree is actually not readable by the current user (even though, this shouldn’t happen I guess)…
Exactly that made me wonder. At first I thought, should it be sudo find but then it should also be sudo chmod and sudo chgrp before and after find. If you sudo it all, then why not sudo ./script instead.