Operating Systems 2022F Lecture 8
Video
Video from the lecture given on October 4, 2022 is now available:
Video is also available through Brightspace (Resources->Zoom meeting->Cloud Recordings tab)
Notes
Lecture 8
---------
Tutorial 4 covers SSH & permissions/users/groups
- we'll discuss SSH later, it isn't on the midterm
When you do "ls -la", you see lots of things. We'll try to explain them now.
- files & directories
- last modified date/time
- file size in bytes
- file owner and group*
- file permissions*
- link count (between permissions and the file owner)*
- total block count
Associated with every file is a uid and a gid
- user ID and group ID
- mapped to usernames and groups in /etc/passwd and /etc/group
(by default)
Why have a uid and gid for each file? Because that determines who can access a file. Specifically, which processes can access which files.
access: open or execve, basically
Because every process also has uid's and gid's:
uid - user ID
gid - group ID
euid - effective user ID
egid - effective group ID
every process has these, and these determine what files can and cannot be accessed
Normally, euid=uid and egid=gid.
- Permission checks are done with egid and euid.
- but the process is "owned" by the uid and is part of the group gid
Basic permission checks
- First, check whether file's user ID matches the accessing process's euid.
- if equal, use the first set of permission bits (user bits)
- if not, compare the file's gid with the process's egid
- if equal, use second set of permission bits (group bits)
- otherwise, use the third set of permission bits (other bits)
For user, group, and other, we have three bits:
read: r
write: w
execute: x
Each bit can be set to 1 (you see the letter)
or it can be set to 0 (you see a -)
File permissions can be confusing. I'm explaining the basics.
BUT YOU SHOULD DO EXPERIMENTS. That's the point of the tutorials
You can also express permission bits using octal numbers
4: read bit
2: write bit
1: execute bit
read and write bits control what open does (for reading and writing)
execute bit is for controlling execve
- bit set: execve will try running it if asked
Remember that file extensions mean nothing on UNIX, it is just a convention
In the shell, "source" causes a shell script to be loaded into the current shell process (bash)
- if you just run a shell script, it gets its own copy of the shell (bash)
There are actually a few other letters that can show up in the first entry:
- regular file
d directory
p pipe <--- after midterm
c character device <--- after midterm
b block device <--- after midterm
s symbolic link
Remember that file permissions, ownership are file metadata. Normally when we download information from other sources, only data is transported, not metadata.
- difference is in archive files (.zip, .tar.gz, .rar, etc),
- they contain metadata information, that way it can be restored
when the archive is unpacked
Now on UNIX there is a user who can get around permissions.
that's the root user, uid=0
If you are running with euid=0, file permission checks are ignored, you
can access everything
- that's why gaining root access is so dangerous
All the sudo command does is execve a program so that euid=0, uid=0
(runs it as root)
Note that /bin/ls is owned by the user root and the group root
- this is good, that means that nobody but root can change /bin/ls
- same for all system binaries in /bin and /usr/bin
But when you do an execve of /bin/ls, it will run with the uid and gid
of the process that did the execve call
- it won't gain any additional privileges
When a proces does an execve, its uid and gid does not change...
UNLESS the setuid and/or setgid bits are set!
there is actually a 4th bit associated with each set of permission bits
- r, w, x, and s
- s is for "setuid/setgid"
- if the s bit is set, if you do an execve of the file,
the process's euid or egid will be changed to be the uid or gid of
the process (depending on whether it is set on the user or group)
- (no set bit for other)
While we talk about setuid root mostly, you can do setgid,
and it can be for any user
- this is part of how /etc/shadow is implemented
Remember there really aren't users in UNIX as an entity
- we have processes and files
- users and groups are labels applied to files and processes, that
control how they can interact
So in a shell, what permissions do internal commands have?
- they are implemented with code inside of the shell binary, so
they can do anything other parts of the shell's code can do
- so yes, full access, unless limited (through additional code)
How does UNIX decide whether a user is authorized or not?
- by default, checks the password
- but doesn't store the password itself, just a hash of the password
- secure hash, so you can't turn the hash into the password,
you'd just have to keep guessing until you found the one
that had the right hash
Now we have to let everyone have access to account information
- otherwise you wouldn't know who owned which files
But we don't want everyone to have access to password hashes
- could use to do "offline dictionary attacks" (look it up)
So account info is in /etc/passwd, /etc/group, except for
password hashes, they are in /etc/shadow, /etc/gshadow
(Note there are other ways to manage who can access a UNIX system,
this is just the standard way and given the way we use Linux today,
it is more than enough.)
Associated with every process is a current working directory (CWD)
- relative filenames are interpreted relative to this directory
- can be changed with the the chdir system call
- needs to be internal in a shell normally,
because if a child process does chdir it won't affect the parent
- and this is always the case for external commands
the SSH part of T4 is to help you learn about SSH because it is useful
- but I won't be testing this material
- happy to answer questions
Remember chsh just changes /etc/passwd, you need to login again
for the changes to take effect