Video summary
The video explains a common access control scenario in Linux where a user named Michelle needs to share a program called "make unit report" with the rest of her company without exposing confidential employee data stored in a separate file. Initially, the program is restricted so that only Michelle can execute it and read the sensitive data file; other employees like Stephen receive a permission denied error because they lack the necessary execute rights on the script. When Michelle attempts to solve this by granting read and execute permissions to the group and others using the chmod command, she encounters a new problem: while Stephen can now run the program, he gains access to the confidential data file as well, which violates security policies.
To resolve this conflict between usability and security, the video introduces the Set User ID (SetUID) bit as the solution. When the SetUID bit is enabled on an executable file, Linux temporarily assumes that the program is being run by the file's owner rather than the actual user executing it. In this specific case, when Stephen runs Michelle's program with the SetUID bit set, the system grants him execute permission but treats the process as if Michelle herself were running it. Consequently, the program can successfully read the confidential data file because the operating system checks permissions against Michelle's ownership, not Stephen's.
However, this privilege is strictly temporary and limited to the duration of the program's execution. As soon as the program finishes, the user immediately reverts to their original identity, meaning Stephen cannot access the data file or browse Michelle's home directory afterward unless he has explicit permission. The video also highlights important technical constraints, noting that SetUID only works on compiled binary programs and has no effect on scripts written in interpreted languages like Python. Furthermore, while this mechanism allows for necessary resource sharing, it is acknowledged as a potential security risk if misused, so administrators are advised to apply the SetUID bit carefully and only when absolutely required.
Read the full video transcript
In a previous video, we saw that our
user Michelle in the manufacturing group
has a program named make unit report
that reads information from the units
produced.dat file.
This data file contains confidential
information about the employees as well
as the number of units they have
produced.
As the permissions are currently set up,
Michelle is the only person who can run
the file or read the data file and it
works great for her.
When she runs the program, she gets some
totals.
But if Stephen from the sales department
tries to run the program
by going to Michelle's home directory
and running make unit report,
he gets a permission denied error.
Here's what's happening.
When Steven requests the program,
Linux sees that Steven is not Michelle
and is not in her group.
That means he is other
and there's no execute permission for
other
and that's why Steven got that error
message.
But knowing this information about units
produced is important to everyone in the
company.
What if Michelle wants everyone in the
company to be able to run the program so
they can see the results as well?
Michelle tries to fix this by adding
read and execute privileges for group
and other to the program.
She does a chod command.
And for the group and other, she sets
their permissions to read and execute
for make unit report.
And there are those permissions.
She can still run the program just fine.
Now when Steven tries running the
program again,
he gets a different error message.
Instead of telling him that the
permission was denied, he gets a message
saying that the units produce data file
cannot be opened for input.
Here's what's happening. Steven makes
his request
and this time Linux finds that he has
permission to run the program.
The program starts running and requests
access to the data file.
Linux checks it, finds that the program
being run by Steven has no permission to
read that file and denies permission.
The program was running, but the data
file that it needs was not accessible.
Now Michelle has a problem. She can't
add read access for her group and other
because that would open up the
confidential information in the file to
everyone.
The solution to this problem is to use
set UID.
When a program has set UID permission,
Linux uses the effective ID of the files
owner instead of the real ID of the
person running the program.
In other words, while the program is
running, Linux presumes it is being run
by the files owner and uses the owner's
permissions instead of the permissions
of the person who's actually running the
program.
You can set UID symbolically with plus S
or numerically by preceding the normal
threedigit permission number
with the digit four which stands for set
UID.
If this is Michelle's file before,
then after she types this command,
this is the result.
Notice that the owner permissions now
end with S instead of X
and the shell highlights the file in a
different color to indicate that it is
set UID.
Now what happens when Steven runs the
program?
We start off just as before
and then Linux detects the set UID
permission
and it runs the program as if the user
were Michelle, the owner of that file.
Now when the program asks to open the
data file,
Linux sees it as Michelle making the
request and grants it.
Let's see this in action.
Michelle is going to set UID for her
program
chod
and for the user group and other
she's going to add set UID permission
on file make unit report
and there's the result.
the program still works fine for her.
And when Stephen runs the program,
it works for him, too.
As soon as the program ends, Steven
resumes his Real ID. So, he cannot look
at the data file.
If he tries to look at Michelle's home
directory
and look at units produced.
He'll get permission denied because he's
now Steven. He's not running a program
as Michelle.
By using set UID,
Michelle can allow other people to use
her program without revealing the
confidential information in her data
file.
In summary, set UID lets other users
temporarily become you for the purposes
of running your program.
You can only set UID on compiled binary
executable programs.
It has no effect on programs that are
written in interpreted languages like
Python.
Because set UID lets one user run a
program with the permissions of another
person, if used improperly, it can be a
security risk.
Use set UID carefully and only when
necessary.