I cannot actually remember how it happened. I wasn’t paying enough attention and was viewing one of my scripts on production. When I was finished I did what I always do in vi – I exited the script using : x which actually saves and exits. In this instance instead of getting an readonly error it actually saved the file. I almost had a heart attack.
This shouldn’t have saved as my guest user has only viewing rights.
The good news was that I actually didn’t make any changes to my script but how exactly did my script end up as read/write for everyone (ie chmod O+rw myscript.sh) and their dog.
Well, I started by checking my development project and the package that gets built from it. I was, an still am, happy that my package build script does use 755 to make sure that my work doesn’t get changed by bad actors.
I can only assume that the package installation process somehow modifies the file permissions. This is being followed up on but I was curious just how wide spread this was. I did some further checking and there is a easier way to determine which files than editing each one.
Find
I wish I knew the back story on the find command as there is probably a lot of interesting stories how those features came into being. In my case, on Solaris, there is a argument that will allow you to search for a specific file permission.
find /path -perm 777
This simplest call will show you a list of all rather naughty file permissions. This is however a rather crude way of searching. You might want to know which permissions world users have but are unconcerned with those for owner or group.
Find still has you covered. It is possible to check for read,write or execute permissions or any combination thereof for user, group or world. The method is actually very similar to the chmod command.
find /path -perm -o+rwx
This command will return a list of all files that are defined as read, write and execute for everyone on the machine. This should hopefully be a very small number of files or at least they should be some simple developer files (on a test machine).
Of course there is a second syntax for producing the same output.
find /path -perm -o=rwx
This syntax might be a bit more intuitive if you are not very familiar with unix.
It is possible to even go one more step and check for files that have the SUID set. This is done in exactly the same way as the other permissions.
I have run this SUID check on my personal computer and you can see a very reasonable list of files that would have that bit set.
myuser@laptop ~ $ find /bin -perm -u+s -ls 5242947 32 -rwsr-xr-x 1 root root 30800 Jul 12 2016 /bin/fusermount 5242997 140 -rwsr-xr-x 1 root root 142032 Jan 28 2017 /bin/ntfs-3g 5243023 44 -rwsr-xr-x 1 root root 44680 May 7 2014 /bin/ping6 5242927 40 -rwsr-xr-x 1 root root 40152 Jun 14 23:51 /bin/mount 5242931 28 -rwsr-xr-x 1 root root 27608 Jun 14 23:51 /bin/umount 5243049 40 -rwsr-xr-x 1 root root 40128 May 17 01:37 /bin/su 5243022 44 -rwsr-xr-x 1 root root 44168 May 7 2014 /bin/ping myuser@laptop ~ $
In the end, I never did hear back why my files changed their permissions but the problem was corrected. This particular command might be an interesting command to keep in mind for budding system administrators.
