- All right, in this demo, I want to show you
how to work with the special permissions.
And to start with, I am going to create a file
in user linda home directory.
So /home/linda and I'm calling it playme.sh.
It's a shell script, so .sh for the convenience of the user.
And let me make it a decent shell script.
In a decent shell script, you always start with this line
to make sure that it is interpreted the right way.
And then I'm using a friendly message,
echo, do you want to play?
Then, we want the shell script to stop,
to do something with the user answer.
Actually, if you just put read,
then you stop the shell script,
but you ignore what the user is typing, that doesn't matter.
And next we are using rm -rf / --no-preserve-root.
Does that sound like a good idea?
Probably not, but I want to make a point here.
And the point is that I'm going to make it executable.
So sudo chmod +x /home/linda/playme.sh.
And now I am going to open a shell as user linda.
So sudo su - linda
and user linda comes in her home directory,
finds this playme.sh.
So user linda is going to use playme.sh.
The big question is, if you saw Linda
is going to press enter, then the script is going to try
to remove the entire root directory.
What do you think, is it going to work? Yes or no?
Well, the answer is no
because the script is executed by user linda.
And that's the essence here.
Now, lets talk set user ID.
I'm going to repeat this command and I'm using
sudo chmod u+s because u+s,
that's how you can set set user ID on playme.sh.
Let me log in as user linda again.
So sudo su - linda and ls -l.
And what do we see?
We see that playme.sh is marked in red.
We also see on the location where normally
you see the x for execute for the user,
we now have lowercase s.
Lowercase s means that set user ID applies
and normally set user ID means
that the script will execute as the owner of the script.
How does that work?
Linda runs it.
While running it she opens the sub shell
and in that sub shell, the script would execute as root.
And you know what playme.sh is going to do in that case?
It will remove all of the files
from the entire roots directory
because Linda is running it as root.
That's what set user ID is doing.
Now the good news is that the bash shell has protection.
The bash shell denies set user ID on bash scripts.
Fortunately, but I wanted to make the point
of what set user ID is doing.
I also want to show you when set user ID is useful.
Honestly, I never ever used it in my entire life
while working with Linux, which is about 30 years already,
but some commands need it.
I'm using sudo find / -perm /4000.
And what do we get?
We get a couple of files
including a file called, where is it?
Passwd.
Passwd is your password file, it has set user ID.
ls -l /usr/bin/passwd is showing the set user ID.
What does that mean?
That means that while the user is running passwd,
the user is in a root shell.
And that is because in order to change your password
you need to edit the contents of /etc/shadow.
And /etc/shadow is a file that is owned by a root
where no permissions apply.
So you need to be the special root user
and the special root user can change the password.
Well, any user can update their password in /etc/shadow
and that is possible because of set user ID.
Now, what I would like to suggest,
never ever use set user ID, but do keep an eye on it
because if ever your system is getting hacked
and the hacker wants to create a backdoor
then set user ID is a popular backdoor.
So you know what, you sudo find /-perm /4000
and copy that to a file with the name /tmp/suid.txt
and that will create file with name suid.txt, cat suid.txt
and we need to do that in the tmp directory, of course.
Do this regularly as a chrome (indistinct)
That's a topic that I will tell you later about
and after doing it again and again and again
compare the contents of this set user ID file.
You know what, let me do that real fast.
I am going to remove it this time
because that would have the same effect.
Sudo chmod u-s /home/linda/playme.sh
I'm going to run my find command again.
Let's call it sudo new.txt
and then I'm going to run a new Linux command
that we have not seen before.
Diff, diff is showing you differences.
I wanna see differences between /tmp/suid.txt
and /tmp/suid-new.txt,
which is showing me what?
Which is showing me differences.
A smaller dent sign, interpret the smaller dent sign
as an arrow to the left, which means on the left
we do have this lindaplayme.sh, on the right we don't.
This is an easy way to find out that there are differences.
And that is how you can do a little bit of monitoring
of this set user ID permission by using the diff command.
Right, let's also talk about set group ID.
Set group ID on files is doing the same
as set user ID on files with the difference
that the user will execute with the permissions
of the group owner.
That's kind of useless.
I don't wanna spend time on that.
I do wanna spend time on set group ID on directories
because that is actually a very convenient,
very useful command.
If you use sudo ls -l /data/sales, what do we see?
We see the file that Linda has just created.
Linda is a member of the group sales, remember?
And other people are a member of the group sales as well.
Now, what is the purpose of creating
such a shared group environment?
Well, the purpose is that people who are a member
of the same group can work in the same files.
Now, the question here is can you user laura
who is also a member of the group sales,
write to the file that Linda created?
And the answer is no, she can't
because Laura is not Linda.
Laura is not a member of the group Linda.
So Laura is others and others is read only.
So Laura can read, Laura cannot write.
The best thing that Laura could do
is copy the file to a new file.
What if you want the user to be able to write to the file?
Well, set group ID on a directory makes that
files created in that directory will get
the same group owner as the directory.
So I am going to use sudo chmod g+s /data/sales.
It's a directory permission.
Let me double check that the permission was set correctly.
Do you see the difference?
S on the position where previously we had x.
We still have x but this position is a shared position.
So s indicates that we have set group ID as well as execute.
Now, I'm going to open a shell as user linda again.
So sudo su -linda.
Linda goes to data sales and Linda is going to use
touch lindafile and ls -l and oops.
I need to create a new file,
lindafile2 and ls -l and now we can see the effect.
Lindafile2 is owned by the group Linda
and oh boy, something else is still not being alright.
The group linda doesn't have right permission.
That's something else that we need to change.
That will be up in the next lesson.
That is Umask.
So, hold that thought, we are getting back on that
in the next video.
But for now one more thing that I wanna tell you about
and that is the following.
Let me use sudo su - laura.
So I'm becoming user laura.
User laura is going to data sales and user laura
sees all these beautiful files that Linda has created.
Now, let me remind you what exactly the permissions are.
And the question is user laura is going to use
rm -f *, can she do that?
Well you remember, removing files
is actually a directory operation.
User laura is a member of the group sales.
Group sales has right permission on the directory.
So user laura is capable of removing files
that Linda has created.
In case you don't like that, you need sticky bit.
Sticky bit is a directory permission
and if sticky bit is set on a directory,
you can only remove the file if you own the file
or if you are the user owner of the directory.
So let me use chmod +t
with sudo, of course.
Chmod +t /data/sales
and again ls- ld /data/sales.
And there we can see, we have an uppercase T right now
and the uppercase T means we have sticky bit
meaning that users can delete their own files.
So, I am using Ctrl+R to reverse-i-search
to get back in the laura shell.
And Laura is going to /data/sales and rm -f *
and there we go, operation not permitted.
Ain't gonna happen.
It's no longer permitted because of sticky bit.
Sticky bit and set group ID are useful permissions
in a shared directory environment.
Set group ID is mainly useful if when a user creates a file,
the group gets right permissions as well.
That's something that's still open
and I will explain in the next video.