Who Is Doing What?

A user is not a process.

A process is not a service.

A service is not a machine.

Those sound like obvious distinctions until a troubleshooting note says something like:

The server is using the admin account and the service is broken.

Which server? Which account? Which process? Which service? What does “broken” mean? What evidence supports any of it?

Week 2 begins by replacing vague system language with a model you can inspect.

Start with identity

An operating system needs a way to decide who is requesting access to a resource.

That identity might represent:

• a human user;
• an administrator;
• an automated service account;
• a background system identity; or
• another constrained application role.

The identity matters because permissions are attached to it directly or indirectly.

A service does not need to “be a person” to have an identity. In fact, giving different services different identities is one of the ways an operating system limits damage when something fails.

Then trace the process

A process is a running instance of a program.

A program file sitting on disk is not yet a process. When the operating system loads and runs it, the process receives runtime state such as:

• a process identifier, usually called a PID;
• an owner identity;
• memory;
• open files;
• environment/configuration;
• child processes; and
• access to system resources allowed by its identity and other controls.

Two processes can run the same program at the same time and still have different PIDs, users, arguments, files, or network connections.

That distinction becomes important when you ask “which instance produced this evidence?”

What makes a service different?

A service is a function the system is expected to provide over time.

Examples include:

• serving a web page;
• resolving names;
• recording logs;
• scheduling jobs;
• storing a database;
• providing remote access; or
• processing messages from another system.

A service may be implemented by one process or many processes.

The useful mental model is:

SERVICE = expected function
PROCESS = running implementation
IDENTITY = permission context
RESOURCE = thing the process needs to use

Synthetic process inventory

Consider this fictional Robotnix classroom system:

RNX-LAB-SVC-01

It provides a status page for a simulated robotics lab.

You are given this synthetic process inventory:

PID   USER          COMMAND           PURPOSE
412   root          system-manager    starts/manages background services
733   rnx-status    status-web        serves the lab status page
748   rnx-status    status-worker     reads generated status data
901   student       text-editor       edits the student's local notes
944   root          log-service       records system/service events

Do not ask “which process looks suspicious?” yet.

First build the system model.

Process 733

Identity: rnx-status
Process: status-web
Likely service: status page
Likely required resources: configuration, status data, a listening socket, logging
Unknown: exact files, exact network binding, exact permissions

That final line is important. A process list tells us some things and leaves others unknown.

Process 901

A student-owned text editor is not automatically a security issue because it exists on the same machine. Its relevance depends on the system question.

If the question is “which process implements the status service?”, Process 901 is probably context, not primary evidence.

Privilege is not the same as legitimacy

A root-owned process can be legitimate.

A non-root process can be misconfigured.

An approved user can perform an action outside the intended boundary.

This is why “high privilege = bad” is too simple.

A better question is:

Does this process have the permissions required for its job—and more than it needs?

That is least privilege as a systems question.

Relationship map

For each process involved in a service, trace:

IDENTITY
  ↓
PROCESS
  ↓
PURPOSE
  ↓
REQUIRED RESOURCE
  ↓
PERMISSION

Example:

rnx-status
  ↓
status-worker
  ↓
read robot status data
  ↓
/var/lib/rnx/status.json
  ↓
read required; write may not be required

Notice how the security question appears only after the mechanism is clear.

If the worker only needs to read status.json, write permission would be an unnecessary capability unless another requirement justifies it.

Local Linux observation path

If your instructor provides an isolated Linux VM or container, these commands are useful for observing your own approved environment:

id
ps -eo pid,user,comm,args

id describes the current identity context. ps gives a process view.

These commands do not prove why a process exists or whether it should have a permission. They give you evidence for the next question.

No-Linux alternative

Use the synthetic process inventory in this lesson. You can complete the required artifact without shell access.

The course never treats access to a particular operating system as permission to inspect unrelated systems.

Activity: trace responsibility

Use the inventory to answer:

1. Which identities appear to be service identities rather than interactive student identities?
2. Which two processes appear to cooperate to provide the status service?
3. What evidence would you need to prove which files those processes use?
4. What evidence would you need to prove which network socket the web process uses?
5. Why would “the server is running as root” be an inaccurate description of this inventory?

Strong answer pattern

A strong answer separates observed from expected:

The process inventory shows status-web and status-worker owned by rnx-status. Their names and supplied purposes suggest they implement the status service, but the process list alone does not prove their open files or network bindings.

That is much stronger than pretending the table tells us everything.

Build your Service Responsibility Map

Start your Week 2 artifact with one row for each service-related process.

Do not fill unknowns with guesses. Unknowns become the evidence plan for Lesson 2.

Before you leave

You should be able to explain this sentence:

A service is an expected function implemented by one or more processes running under identities that determine which resources those processes can use.

That sentence is the bridge from basic operating systems to defensive security.