Soma: Created page with "==Video== Video from the lectures given on October 6th and 7th, 2026 are now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec07a-20261006.mp4 Lecture 7A] * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec07b-20261007.mp4 Lecture 7B] ==Notes== ===Lecture 7A===

 Lecture 7A ----------  Tutorial 4!  Apps ------ Kernel  <--- has more privileges ------- Hardware  Implemented on the CPU through..."

2026-10-07T17:57:17Z

Created page with "==Video== Video from the lectures given on October 6th and 7th, 2026 are now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec07a-20261006.mp4 Lecture 7A] * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec07b-20261007.mp4 Lecture 7B] ==Notes== ===Lecture 7A=== <pre> Lecture 7A ---------- Tutorial 4! Apps ------ Kernel <--- has more privileges ------- Hardware Implemented on the CPU through..."

New page

==Video==

Video from the lectures given on October 6th and 7th, 2026 are now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec07a-20261006.mp4 Lecture 7A]
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec07b-20261007.mp4 Lecture 7B]

==Notes==

===Lecture 7A===

<pre>
Lecture 7A
----------

Tutorial 4!

Apps
------
Kernel <--- has more privileges
-------
Hardware

Implemented on the CPU through different modes.

UNIX-like systems expect there to be a supervisor mode and a user mode.
- supervisor mode: can access everything
- user mode: limited access

processes run in user mode
the kernel runs in supervisor mode

a "process" is an abstraction over sharing of user mode

the kernel doesn't share supervisor mode - that's all that runs

Linux
- name of an implementation of a operating system kernel
- designed to be basically compatible with POSIX

POSIX
- set of standards defining what a UNIX-like system is

UNIX
- operating system created by engineers at Bell Labs (AT&T) in the early 1970's

AT&T had been ruled a monopoly so they had lots of rules about what they could and could not do
- they weren't allowed to compete in the commputer market
- but their engineers made a nice OS
- so, they basically gave away UNIX
- very permissive licenses
- adopted by a lot of universities, esp ones who were developing the Internet

UNIX is a pun on MULTICS

BSD UNIX - Berkeley variant of UNIX that was where a lot of Internet technologies were prototyped

But then BSD UNIX got big, and so commercial UNIX became a thing in the 1980's
- on scientific workstations and other bigger machines

But every company that made a UNIX workstation made their own proprietary version of UNIX
- permissive license from AT&T plus Berkeley giving away their code

These variations got to be such a pain that there came an effort to standardize what a "UNIX-like" system should be
- this resulted in POSIX

UNIX is trademarked
- not everyone can call their OS UNIX

In the early 1990's two things happened
- The web arrived (1992-1993)
- CPUs capable of UNIX became available in PCs
- 80386 starting in 1985
- 80486 starting in 1989

So a commercial UNIX could have taken over
- Microsoft actually sold XENIX for PCs

But really a version of BSD UNIX should have been available for PCs around then and should have been the foundation of the modern Internet
- was open source and battle tested

What happened?

AT&T got greedy
- was free of antitrust concerns
- and UNIX had become valuable
- so they went and sued the people who were making BSD UNIX

Linux is the product of three things
- AT&T's lawsuits
- the GNU project not making a kernel
- a finnish CS undergrad hacking around

The GNU project
- project of the Free Software Foundation
- stands for GNU's not UNIX
- FSF people (led by Richard Stallman) got tired of proprietary UNIX
- wanted THE CODE so they could make their own changes and share
them
- so they decided to make their own version of a UNIX-like system

- gcc instead of cc
- bash instead of sh
- bison instead of lex

All under the GPL

GPL - GNU General Public License
- if you distribute, you have to share the source code with binaries
- source code should be distributable under same terms

The GNU project did this for essentially all of userspace of a UNIX system by the early 1990's. But it couldn't run on bare hardware because they didn't have a kernel.
- GNU Herd was stalled

And then Linus Torvalds came along
- got people on the Internet collaborating on making a kernel

People say GNU/Linux because it is the Linux kernel with a GNU userland
- but nowadays that isn't always true (e.g., busybox)

Linux distribution: Linux kernel + some userspace code

So with UNIX, you have code running in supervisor mode (kernelspace) and in user mode (userspace)

We're now focused on userspace, will talk about kernelspace more after the midterm

So when a process wants to do something with files, it must make system calls
- system call is a request to the kernel
- kernel can say yes or no

On what basis does the kernel say yes or no?

Wooclap code: AFAGNUX

First, it depends on which process and which file

Some processes can access everything
Some have limited access

What mainly determines access is the user who owns the process
- i.e., the uid associated with the owner field of the process

Files on UNIX have an associated uid and gid (user and group)
And permissions associated with these.

three groups of read, write, execute bits
- yes or no for each
plus a few other bits

The rwx are for:
- the user
- the group
- other (everyone else)

To read a file, you need read access
- first check to see if uid of process equals uid of file
- and user read bit enabled
- then check gid of process equals gid of file
- and group read bit enabled
- then check if other read bit enabled

But what about directories?
- marked by a "d" bit

When you run ls, you're reading the contents of the current directory
- represented by "."
- ".." is the parent directory

To be able to list

What's really happening is that the contents of a file is represented as an inode
- inodes are numbered per filesystem

A directory is just a mapping of names to inodes

With r permission, you can read the mappings of names to inodes in a directory

With x permission, you can get the inode associated with a name

file permissions are actually inode permission in UNIX

hard links are just name to inode associations
(what directories mostly contain)

symbolic links are name to name associations

So what's special about root (uid=0)?
- the kernel treats those processes as being allowed to do almost anything

When you use sudo, you are saying "superuser (root) do this"
- better than logging in as root, because it is clear what is being done with elevated privileges

If you just want to be root, run "su" - but you need the root password.

Alternately, run "sudo -i" to login as root if your user has sudo privileges.

setuid bit
- goes with the executable bit on a file, but separate

when a process execve's a program with the setuid bit, the *euid* of the process changes to that of the program file
</pre>

===Lecture 7B===

<pre>
Lecture 7B
----------

Wooclap 1: OEHHFJX
Be sure to be logged in!

Today is Tutorial 4, plus some history

Applications (processes)
-------
Kernel
--------
Hardware

kernel and applications take turns on the CPU
- key difference is their privilege levels

So the kernel runs in "supervisor mode", while
processes run in "user mode" on the CPU
- full access in supervisor mode
- limited access in user mode

the process abstraction is a way to multiplex user mode

System calls are how code in user mode invokes code in supervisor mode, i.e., how processes call the kernel
- special mechanism because function calls don't work

So what are permissions for?
- tells the kernel what privileges different processes should have, i.e., what resources it should be given access to

We mainly see permissions associated with two things:
- processes
- files

So when a process accesses a file, the kernel decides whether it is allowed or not based on the permission model

Permissions are generally in some sort of access control matrix
- rows are entities
- columns are specific permissions
UNIX uses a simplified access control model for efficiency and usability

I've been saying UNIX, Linux, UNIX-like...why?

UNIX is a trademark of AT&T
- because it came out of Bell Labs in the early 1970's
- wasn't really a product at first because was
just made by a few engineers for their own use
- and AT&T wasn't allowed to commercialize it really
- they were under antitrust restrictions
- so they almost gave it away
- very open license terms for whomever wanted it

When researchers wanted to create the Internet in the late 1970's, they mostly built upon UNIX
- researchers at Berkeley modified it to make BSD UNIX

So to get on the Internet people wanted to run BSD UNIX, and so it spread
- first as itself
- then in commercial form from workstation vendors in the 1980's (e.g., Sun Microsystems)

Because of the licensing terms, workstation manufacturers all could make proprietary versions of UNIX
- based on generally available code but with lots of proprietary modifications/additions

Got so bad there was an effort to standardize what "UNIX" should be
- resulted in the POSIX standards

So UNIX should have been the basis of the web starting in the early 1990's, but a few things happened
- PCs got powerful enough to run UNIX
- Intel 80386 in 1985, 80486 in 1989
- there were commercial versions of UNIX for PCs
- Microsoft made XENIX

Rather than proprietary UNIX, why couldn't PCs run a variant of BSD UNIX?
- it was still around, had its own variants
- but AT&T decided to sue the creators of BSD UNIX

Another piece was the GNU Project
- from the Free Software Foundation
- HATED proprietary UNIX, so decided to make their own

Started with the foundations
- gcc instead of cc
- bash rather than sh
- bison rather than lex

By the early 1990's, GNU had implementations of everything in core UNIX...except for the kernel
- there was the GNU Herd, but it was VERY delayed

This is where a Finnish CS undergrad steps in
- Linus Torvalds posted his own hacked together kernel
- with the help of others, he
combined it with GNU userland, and now had a
UNIX-like system that came to be known as Linux

Strictly speaking, Linux is just the kernel
- to get a full UNIX-like system, need to add userspace
- Linux + userspace => Linux distribution
- people call Linux GNU/Linux because GNU project code
is often part of a Linux distribution
- but not always! (e.g., busybox)

One factor in the success of Linux is its license
- GNU GPL (General Public License)

"copyleft" license
- based on copyright to subvert copyright
- says you can distribute code as you like, BUT
- you have to give source with binary code
- can't add restrictions

Android has effectively circumvented the GPL of Linux
- VERY irritating

Back to permissions

every process has a user and a group
every file has a user, a group, and permissions

The permissions are
- read
- write
- execute
And are there for
- user
- group
- other (everyone else)
plus a few more bits we will discuss

execute for regular files means they can be run as programs
- when you compile a program the compiler makes its
output executable

Other bits:
d: marks a file as a directory
- maps filenames to file contents (inodes)

What do permissions mean on a directory?
- read lets you list the names in a directory
- execute lets you resolve a name to its associated value (i.e., inode)

If a directory is executable but not readable, you can access the contents of files in that directory, but you can't get a list of files in the directory (try it out!)

But this whole permission model begs a question -
how do we get around it?
- how do we get the right permissions in the first place?

One user is very special in UNIX: root (uid=0)
- is allowed to do basically anything by the kernel

So when you first log in, that process is running as root so it can then "become" any user it wants to
- called dropping privileges

But then what about sudo?
- goes the wrong way, from a less privileged process
to one with root capabilities
- "superuser (root) do"

s in ls means that the executable and the setuid bit are both set
- if just setuid and not executable, you get S
(almost never what you want)

With the setuid bit set, the effective uid of a process becomes that of the executable file

The kernel uses the effective uid to decide what is and isn't allowed
- normally uid=euid
- but setuid messes with it
</pre>

Operating Systems 2026F Lecture 7 - Revision history