Now as we've seen that we can set up the correct permissions to
ensure that we can't delete files that we don't need,
still not really proper collaboration.
Without the group ID bit set on the directory,
we can't control the ownership of files within that directory,
and that's what we're going to take a look at now.
Running the ls command,
or just taking a look at the permissions on our admin directory,
we've got the correct ownership, and that is allowing our permissions.
However, when we look inside of the admin directory,
the file that was created by the user root is group‑owned by the user root.
Any files that were created by the vagrant user would be
group‑owned by their primary group ID.
Now it would be unreasonable to expect users to change to
their group ID before creating content, so we can set this up automatically.
We can also, through good use of the umask,
ensure that others don't have permissions through to these files.
So even though we shouldn't have access to the directory
if we're not a member of the group,
we can still see that we are giving world‑readable permissions to this file,
and from a security model, that's not correct.
So let's go through,
and the first thing I'm going to do as an ordinary user
is go through and set my umask to 027.
Setting the umask to 027,
we're ensuring that we're removing all permissions from others and
we're removing the write permission from the group,
but it means that the group should be able to read files that I create.
Setting up the permission on the directory,
if I do a sudo and chmod ‑v, so we see the permissions change,
and we're going to go through and do a g+s for special permission.
So it's t for our sticky bit, but for our user ID bit and our group ID bit,
we use the symbol s, and we're going to add that through to our admin directory.
We can see then that we change from 1770 through to 3770,
where we have the group ID bit with a value of 2 and
the sticky bit set with a value of 1.
We can see the lowercase s being set in the group portion of execute,
indicating the execute permission is set.
If it was an uppercase S,
we would know then that execute wasn't set for the group.
With that done, as I go through then and touch,
and the admin directory,
and we can go through and ensure that we create a new file.
So without doing anything other than creating the file and
with the correct permission set through the umask and the
permissions on the directory, now as I go through and take a look at that file,
we can see then we've got the correct permissions of read/write and read,
the correct ownership of the wheel group,
and this doesn't just apply through to our non‑root account.
When we go through and do a sudo and touch,
as we go through and put our admin directory and root2,
as we look at that when we go back and review,
we can see we've got read/write and read,
permissions are not granted through to others,
but all files created in the directory, new files, not existing files,
but all new files created in the admin directory are going to be
group‑owned by the group owner of the directory.
That's wheel,
and we can see now that everything is working the way that we
want, and we've got proper collaboration working where the wheel
group can read all files created in the directory. And with a
simple use of our umask,
we can ensure that we can set the correct permissions
without having to go through and change permissions on new files created in the directory.