So here I'm going to demonstrate these special permissions.
So what did we do before?
Well LS ld on data sales is showing that I
created directory sales that is owned by the group sales.
And the group sales has read, write and execute permission. Now who's a member of the group sales?
Well let's do a grab sales on etc group.
This is a secondary group and secondary group membership is managed through etc
group. So Anna, Linda and Laura are a member of the group sales.
Okay, now what does that mean? That means that if I open a
shell as user Linda then I go to the data sales directory.
I should be able to use touc and create a couple of files.
And LS L is showing oh I did it wrong.
I needed arrange 1 3.
So ls l is showing all these files.
Now what do we see on these files?
They are user owned by lynda. They are group owned by Lynda.
And in shared group environments maybe it is convenient if the group
ownership is set to the group owner of the parent directory.
What I mean is if Linda is working in the sales group then
the file she creates should be owned by the sales group as well.
So how are we going to do that? Well, sudo chmod g S that's how
you set set group ID on a directory and the directory is data sales.
Now I'm using LS ld on data sales again and what do we see? Well you
see that where before we had RW access to group permissions, now we have rws.
And this rws means that the group owner of the directory is going
to be applied for all files that will be created in that directory.
So if I use sudo su linda again and lynda is using
touch data sales lynda for up to 6 then we use LS
minus L on data sills and there we can see that Lynda
4, 5 and 6 are group owned by the group sales.
Right. Who else was in the group sales?
So let's do the grep command again. Grep sils on etc group
and there we can see Lora is also in the group sales.
Okay, so now I'm going to use sudo sudo su minus lora to
open a shell as user lora. Oh boy, Linda cannot do that.
So let me control c on that and let me exit back to the student shell for the sudo su minus Laura to open a
shell as user lora. Lora goes to data sales and and Laura is going to use RM on Linda 1 and is that allowed?
Well let's figure it out. And yeah, it's allowed. Why is this allowed?
Well, that is because the directory sales. Let's figure out the
properties. The directory sales has write permission for the group.
Laura is a member of the group Sales. Group Sales has write permission. Deleting a file requires write permission on the directory.
And that is something that Lora can do. And if you don't like that, you need sticky bit.
So how do we set that? Well, sudo chmod d on Data Sales, chmod
d is setting sticky bit. I always do sticky bit and set groupid in
relative mode because they are easier LS minus ld on Data Sales is now
showing an uppercase t in the permissions, which indicates that sticky bit is set.
And when we use sudo su to lora again and Lora is
going to try to do an RM data sales, then we get
operation not permitted on all of these files. So I might as
well control C out of it because sticky bit is preventing this.
So sticky bit and setgroupid are actually pretty convenient permissions in a shared group environment.
One more thing we need to talk about, and that is the notation of these permissions.
Do you see that we have lowercase s and uppercase t? And that is
because LS l doesn't have a separate position to show if special permissions apply.
So the convention is that special permissions have a shared position in
the LS l output where you normally have the x for execute.
Now for set group ID that is showing as an s in the group permissions where
you normally have an x and the sticky bit is showing as a t and you
get lowercase if behind the special permission there is execute. You get uppercase if behind the
special permission there is no execute. And that's why we see uppercase t because others had
no permissions at all and lowercase s, but because the group had executed as well on
this Data Sales directory. One more thing, and that is sudo find 4000.
Let me make sure that I don't see any error messages.
This is using the find command to show permissions. And the permission
that I'm looking for here is a set user ID permission.
So what is going on with this user bin passwd? Let's do a LS minus l on user bin passwd.
There we can see it's marked red and at the position of the x for the
user we have an s. And that means that this binary has set user ID permissions.
And that means that while running the command you start a subshell in which you are
the owner of the file. So while running password, you are root. And why do you
need that? Well, you need that in order to write your changes to etc Shadow.
Now isn't that funny? On Red Hat on etc shadow, not even root has permissions. But that doesn't matter,
because root is living in a world where permissions don't matter. Root can always write, and when an ordinary
user is using passwd to change their password, well, this makes that the ordinary user is temporarily becoming root.
Set user ID is needed for some commands. You can see a list of these commands on my system right here.
For all other cases, set user ID is very dangerous and should be avoided at all times.