To begin with,
we're going to take a look at using collaboration and
special permissions set on directories.
So we'll take a look at the sticky bit first to get an idea of how that is
used before moving on to using the set group ID bit.
We can set the group ID bit on a directory to ensure that all new files within
the directory are owned by the group owner of the directory.
In our first demonstration,
we'll move into this straight away and take a look at the need of
the sticky bit by setting up a shared directory,
a directory that we can use for collaboration.
And here we are, the glorious command line of our alma8 system.
We need to go through and check the groups that your user account belongs to.
Now we can see that in my case, I belong to my private group,
the vagrant group, based on my user account,
but I don't belong to any additional groups.
If we're going to set up a directory for collaboration,
typically, we're going to be making sure that it's shared out towards a group.
So we're going to just modify our group membership of our ordinary account
just to ensure that we belong to an additional group.
So using sudo and usermod,
we can go through and obviously modify a user account
appending ‑a to the uppercase G, the complementary groups,
and we're going to just add in the wheel group.
This is an administration group that's there on our Red Hat‑based systems.
If you're using a Debian‑based system,
then you might go through and choose the sudo group.
Now with that done, we are a member of the group,
but it won't show as an effective group,
as we can see, until we log out and log in again.
Let's quickly log out, log back in again.
Once we've logged back in again,
we're going to see then that we are contributing towards the wheel group.
Now the idea of using the sticky bit on a directory is to
allow a directory for collaboration purposes.
To create content in a directory,
you do need to be able to write to the directory.
But we don't want the fact that you can write to the directory,
meaning that you can delete any content from the directory.
If we go through and just take a look at our standard directories,
so ls ‑ld on the /tmp directory,
we can see the lowercase t in place for others indicating
that the sticky bit is in place here.
We want users to create content inside of the temp directory,
but they should only be allowed to delete content that they own, and we
want to do this on our own shared collaborative directory,
and we're going to create that now.
We're going to create it at the root of our file system,
so we're using sudo and mkdir, and we're just going to call it /admin.
If it's for the administration group,
then it kind of makes sense that we call it admin,
although it really doesn't make any difference.
Now we want to make sure that the group ownership is correct.
We want to share this towards our, in my case, wheel group.
But if you're using a different group,
put your group name in there for the admin directory.
Now that, of course, then doesn't change any of the permissions,
it only changes to the group ownership.
So when we go through into a long listing of our admin
directory and don't forget the d for directory,
so we look at the permissions of the directory not in the directory,
we can see then that it's correctly owned by the wheel group,
but others have access into that group or that directory as well.
So we can go through and make sure that others don't have
access or others equals and no permissions.
Now, that then, makes sure then that others don't have access,
but we also need to make sure that the group can write.
If the group, the wheel group, is going to be allowed to create content,
they need the right permission.
Not only can we set the permissions in one lump,
we don't need to do it separately,
but we're just building it up to make sure we get the
understanding of what's going on, so group plus w.
Now that's everything that we need,
so we can go ahead as an ordinary user who's a member of the wheel group,
and we're going to be able to then create new
content within our admin directory, which is the design of this structure.
So we can, again, create a file called vagrant,
but as the root user as well, so sudo.
Let's do the same type of process where we go through and create a file,
maybe called root.
But the downside of this,
if I go through and take a look inside of the admin directory,
even though we don't have permissions as a vagrant user
to be able to write to the root file, we can only read it through others,
we are able to delete all content in this directory.
We can write to the directory, that's what write permissions mean.
Writing directory is creating and deleting content.
Essentially, a directory is a list of files.
So if I try and do an rm /admin/*,
we're getting a warning about the read‑only file.
But I can bypass a warning saying, yes, I'd love to delete that.
Now when we look inside of the admin directory, it's empty.
Now thus, we might be very happy with ourselves,
it's not really the design of this file system.
So we can go in and ensure,
I'm just going to put chmod ‑v, so we can see the permissions changing.
We're going to add others +t,
so we're going to add the sticky bit to the admin directory.
Of course, it needs to be run with sudo privileges using Ctrl+A for Apple.
We can move to the beginning of the line to add in the sudo,
and we can see then that we change our permission from
0770 to 1770 and the uppercase T.
The uppercase T is indicating then that the execute permission is not set.
Let's repeat, go through creating those files again.
With that done, as we go through now and try and delete our files,
we are prevented from deleting files that we don't own,
so we've achieved our goal.
Let's go back, though, and just look at the permissions.
We've seen the uppercase T,
but if I add executing for others for the admin directory,
we can see it changes to the lowercase t just as we saw with the temp directory,
so we can still see that execute is set or not set by the case of our symbol. When we change it back to other ‑x, we can see it returns to the uppercase T.