Ubuntu: Setting group ID for website development folder

Having recently migrated to Ubuntu I wanted to have all my website projects stored in my home folder but allow Apache to load them from there.

This has given me a little bit of a headache when it comes to permissions and ownership. Warren Daly helped out and did some CLI magic which I haven’t yet fully documented but I’m starting to get a handle on how it’s all working.

One issue which did crop up was that any files I was creating/copying into the /home/websites folder was ending up with the wrong permissions. Ideally I wanted every new folder to be 755 and each new file to be 644. This should then allow Apache the permissions it needs.

Fortunately this can be easily achieved by setting the sticky bit.

find websites/. -type d -exec chmod 2755 {} \;

This command is a handy one for searching for all folders (“-type d”) and executing a chmod command on them. Usually we’d just run 755, but in this case we’re adding the sticky bit at the front of the command to set these folders to always have new files at 644 and new folders at 755.

I think.

It’s going to take me a little while to fully get my head around a new world of permissions, ownership, group handling and so on, but hopefully I’ll get there sooner rather than later.

If you list your files/folders after this command you should see something like this:

Folders and files with sticky bit set

My understanding of it is that the d shows our directories, and the ‘s’ you see in the directory permissions is setting the sticky bit to the user or group ID. Perhaps Warren will be able to clarify that fully for me.

Comments

  • Warren Daly

    SUID, SGID and Sticky bit all reside in the 9th to 12th permission bits.
    In general one must remember to never alter the SUID (Set owner User ID up on execution).

    SUID gives temporary permissions to a user to run a program with the permissions of the file owner rather that the user who runs it. So if the file is owned by root, and the SUID is set, a user can execute this file….. you can already begin to see where problems arise.

    A real world example of a programs that has it’s SUID set is ‘passwd’…. when a normal user wishes to alter their password, they use #passwd, but in order for passwd to complete it’s task, it needs to alter /etc/passwd and /etc/shadow. These files cannot be opened or read by a normal user, only root. This is where SUID comes in to play. It’s extremely powerful and extremely dangerous.

    # ls -lrt /usr/bin/passwd
    -rwsr-xr-x 1 root root 47064 ៧ 27 00:32 /usr/bin/passwd

    Some say that you should utilize the SUID command when you don’t want to give a user SUDO access. However, this is no longer true, as you can edit a list of SUDO commands for a single user. So, SUID is not needed. And another reason never to use it. Or if you are, seriously contemplate why and if there is another solutions.

    • Wow, thanks for the comment. Definitely looks like I’ve still got a ways to go before I fully understand linux permissions!