So far, we have been talking about basic permissions.
There's also special permissions.
And these special permissions have been
introduced for special cases.
And the only case still relevant nowadays
is a case where you want to configure directories
for shared group access.
So I'm not going to cover all the special permissions
and their use cases, because some of the use cases
will never, ever happen.
So if members of the same group need
to share files within a directory,
some special permissions are required.
The set group ID permission, also known as SG ID,
ensures that all files created in the shared group directory
are group owned by the group owner of the directory.
And the sticky bit permission ensures
that only the user who is owner of the file
or the directory that contains the file
is allowed to delete the file.
Another special permission is set user ID, or SUID,
which ensures that the program file well executed
is executed with the permission of the owner.
And this is used as a default setting
on some files, which should never
be applied, as most files are owned by the root user.
So how do you change these permissions?
Well, I like the relative mode to do so.
CH mode G plus S is setting set group ID to a directory.
And CH mode plus D will assign sticky bit to the directory.
You'll only assign these permissions to directories.
On files, there's limited use.
Now, in absolute mode, you can also change them.
And then a four-digit number is used,
of which the first digit is for the special permissions.
CH mode 3770 would assign set group ID and sticky bit,
as well as RWX for user and group.
Let me show you how this works.
First, I'd like to show you something about the permission
that you should never use, set user ID.
I'm going to use find slash minus perm slash 4000
to find files that have the set user ID permission.
So what does it mean?
It means that these files take the permission of the user
owner of the file while being executed.
And that is actually very dangerous
if used in the wrong way.
But let me show you why it's happening on user bin pass WD.
So user bin pass WD is showing a little S, RWS.
The S on the position where you normally
find the X for execute, that indicates that this
is a set user ID file.
And you can also see that the file itself
is marked in red, which is the shell's way to indicate
something potentially dangerous is going on here.
So what does it mean?
Well, it means that if an ordinary user is running
the password command, the user is temporarily
having root permissions.
And why do we need that?
Well, we need that because the new password
needs to be written to etcshadow.
Fun thing, etcshadow has no permissions at all.
And in case you are wondering, how is it possible
that the root user can update it?
Well, that's because the root user is a kernel level user.
And in the place where the root user is living,
permissions are not needed.
Root can do whatever root wants anyway.
No permissions needed for that.
Do not ever use set user ID on files
because it is very dangerous.
Now, in the second part of my demo,
I want to show you the special permissions on directories.
So let me create a little scenario.
I'm going to use group add sills to create
a group with the name sills.
And I'm going to use user mod minus AG sills for user Linda.
And let me also create user Lisa.
So I'm using user add minus uppercase G sills for user Lisa.
Ideally, Lisa is showing that Lisa
is a member of group Lisa and group sills.
And that's what we need here.
So I'm going to create directory data sills.
And I'm going to set permissions to 770 on data sills
because we want the group members to be
able to write to the directory.
Now I'm opening a shell as user Linda.
And as user Linda, I'm getting into the data sills directory.
And oh boy, something apparently has gone wrong here.
What has gone wrong?
Hey, can you take a moment to figure it out?
I might have forgotten something.
And I hope you see it.
The thing that I forgot is that I never changed the group owner.
And that's not going to work.
So we currently have 770 where the user and group root
have these permissions.
So let's use CHGRP sills on data sills.
And oops, that shouldn't be done as user Linda.
So let's use CHGRP sills on data sills.
And this time, it might be smart to verify.
I would always advise you verify your current settings
before you're doing anything else.
So here you can see that everything is OK.
And now as user Linda, I should be
able to go to the data sills directory
and use touch on Linda 1.
And ls minus l is showing what?
Showing that the file is owned by user Linda and by group
Linda.
And you might consider that inconvenient
because maybe this is a shared group directory because you
want other people in the group to be able to work
on the file as well.
And that is where set group ID comes in.
So I'm going to use CHMOD G plus S on data sills.
Verify using ls minus ld on data sills.
And there we can see that now we have RWS instead of RWX.
And the lowercase s indicates that set group ID applies.
So if I get back to my user Linda shell
and I get back into the data sills directory
and I use touch Linda 2, look at the ownership.
The file Linda 2 is now owned by the sills group.
And that's what we wanted.
Now there is another problem with these files.
And that's the following.
I'm going to open a shell as user Lisa.
And user Lisa in the data sills directory
is seeing the files that Linda has created.
Now the question is, is user Lisa
allowed to remove a file that Linda has created?
This should be the same case as what we have seen before.
User Lisa is a member of the group sills.
And the group sills has a write permission on the directory.
Let me show you.
Ls minus ld on dot is showing that it is group owned by sills.
And we have rws indicating the write permission
on the directory for the group sills.
So the answer should be yes, user Lisa
is allowed to remove.
And that's the second thing that you
might want to take care of on a shared group directory.
So what do we see?
This time we have uppercase T, which indicates
that there is sticky bit.
And the uppercase T is on the position
where normally you have x for others.
It's an uppercase because there's
no underlying x for others.
And if there would be an x for others,
it would become a lowercase.
Now what is the effect?
Well, let me show you.
I'm going back to user Lisa shell.
And user Lisa is going to data sills.
And in data sills, user Lisa is going
to use rm minus f on Linda 2.
And she is getting operation not permitted.
Why is that?
Well, that is even if user sills has write permission,
if sticky bit applies, a user can only
delete the file if the user is owner of the file
or if the user is owner of the directory, which
means that if Lisa would be the boss of the sills department
and you want to give her special permissions, well, in this case,
you could give user Lisa user ownership of the sills
directory so that she can delete files.
But that's only for exceptional cases and not for everybody.