command line fun – finding security problems with find

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


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.

This entry was posted in Command line and tagged , , , . Bookmark the permalink.