Linux files, permissions & processes

Linux is the reference host environment for the hands-on command examples in this path. This lesson explains the file and process ideas needed to understand later Android source work. Linux on a workstation and Linux inside Android share concepts but not necessarily tools, configuration, permissions, or behavior. Reading this lesson does not inspect a live system.

Before you start#

• Workstation setup — host and shell assumptions.
• Terminal and Git — paths, commands, output, and safe practice directory.

Learning goals#

You can explain absolute versus relative paths, read basic owner/group/other permission bits, distinguish a regular file from directory and symbolic link, describe why /proc is not ordinary stored files, and explain a process's PID, standard streams, exit status, and safe use of Ctrl+C.

Paths and files#

Linux represents files in a directory tree beginning at /, the filesystem root. Do not confuse this with /root, a particular user's home directory. /home/name is a common home path, but systems can differ. An absolute path starts at /; a relative path is interpreted from the current working directory. . means here and .. means the parent. Linux path names are case-sensitive.

A directory contains names that refer to files or other directories. A regular file stores data. A symbolic link (symlink) is a path that points to another path; it can become dangling if its target moves or is removed. A filesystem is a structured way data is made available at a path. Linux can mount different filesystems at directories; therefore, the tree is not necessarily one physical disk. Do not infer that deleting a pathname always deletes the underlying storage object—links, mount points, permissions, and application behavior matter.

Linux ownership associates a file with a user and a group. A user account has a numeric user ID (UID); groups have numeric group IDs (GIDs) and help grant access to sets of users. Names such as learner are human-readable mappings, not the identity mechanism itself. A process typically acts with an effective user/group identity (credentials(7)). File ownership and permission checks use these identities along with other controls; being able to see a filename does not guarantee you can read or change its contents. If you want to inspect these concepts on Ubuntu, ls -l is sufficient for this lesson; do not install or change permissions just to complete it. Optional Ubuntu host tools are described in Workstation setup, including the explicit administrator consent step for APT package changes.

Permission bits are commonly described for owner, group, and other. r means read, w write, and x execute for a file; for a directory, execute means search/traverse it (chmod(1)). Example mode -rw-r----- describes a regular file readable/writable by owner, readable by group, and inaccessible to others. The leading character identifies a type; d commonly marks a directory and l a symlink. A directory often needs both read (list names) and execute (traverse known names) for useful access. This is a simplified view: ACLs, mount options, capabilities, and security policy can add controls.

Host — Ubuntu Bash; read-only inspection of the current directory:

pwd
ls -l

Output varies. A typical ls -l row begins with a type/mode marker, then link count, owner, group, size, timestamp, and name. If there are no entries, that is valid. A symlink row typically begins with l and shows the target after ->; relative link targets are interpreted from the link's containing directory. A mount point may look like an ordinary directory in a listing even though a separate filesystem is attached there. Mounting and unmounting change the host's view of storage and are deliberately not part of this exercise. Linux path resolution

Do not change permissions on system files as an experiment. chmod changes mode bits; it is mutating and easy to misuse. Never copy a permission command from a tutorial without understanding its target and effect. In particular, making files broadly writable or executable to “fix” an error weakens protections and may not solve the actual ownership, mount, or policy issue. Linux chmod(1)

A process is a running program#

A program is stored instructions; a process is one running instance with an execution context and resources. Starting the same program twice can create two processes with different process identifiers (PIDs). A thread is an execution sequence within a process; threads share much of that process's memory, so one thread's bug can affect siblings (pthreads(7)). The kernel is the privileged core of the operating system. Applications normally execute with less privilege and ask the kernel for controlled services.

Programs inherit or create standard streams: stdin (input, conventionally descriptor 0), stdout (ordinary output, 1), and stderr (diagnostics, 2) (stdin(3) gives these descriptors on program startup). The shell connects these to a terminal by default; pipes and redirection can connect them elsewhere. A process also finishes with an exit status. Conventionally zero signals success and nonzero some failure, but only the program's documentation explains a particular value. The shell's $? expansion in Bash shows the last command's status; it is a shell feature, not output to type into another program.

Host — Ubuntu Bash; inspect a simple command's status:

true
printf 'exit status: %s\n' "$?"
false
printf 'exit status: %s\n' "$?"

Expected: true prints no output and is followed by exit status: 0; false prints no output and is followed by exit status: 1. This controlled example shows why empty output alone does not mean an error. The commands do not alter device or host data.

Processes can receive signals, notifications used for control. Ctrl+C in an interactive terminal typically asks the foreground process to stop (SIGINT, signal(7)). This is not a universal undo button: the program may already have changed data, may handle the signal differently, or may be unable to stop immediately. Use it to interrupt a command you understand, not as a safety guarantee. Avoid kill/killall while learning; selecting the wrong process can disrupt work.

Linux exposes some kernel/process information through /proc, a virtual filesystem: entries are generated views, not ordinary files saved like notes on disk. The existence and contents of entries depend on the kernel, permissions, and namespace. Do not write to /proc as a first exercise. Later Android shell access may expose a restricted view; Android policy is not identical to a desktop Linux host. Linux proc filesystem documentation

Why this matters on Android#

An Android app runs as a process with an identity and boundaries. Android combines Linux mechanisms with app-specific identity, permissions, runtime, and security policy (Application Sandbox: each app gets its own UID and process). A shell is also a process with its own identity; having a prompt does not mean kernel privilege. Root is not a synonym for “terminal,” and even UID 0 can be constrained by other controls. ADB commands execute in the device environment only when prefixed through the ADB client; plain pwd in your workstation terminal inspects your host.

These are general Linux concepts. For a device-specific claim, record Android release/build and device context, then consult matching Android source/documentation. Do not use desktop /proc output as proof of Android behavior.

Practice#

Context: host-only, read-only inspection plus two harmless shell built-ins; no device changes. In an Ubuntu Bash terminal, run pwd and ls -l, then run the true/false status example. On paper, identify which output is stdout and which is the printed status line. Describe why Ctrl+C is not an undo mechanism. If ls -l lists nothing, that is a valid empty directory. If the shell is not Bash/Linux, choose source-only mode rather than translating commands by guesswork. Do not run chmod, write under /proc, or kill a process for this exercise.

Knowledge check#

1. What is the difference between /home/learner/notes.txt and notes.txt when your current directory is /home/learner?
2. A file mode begins -rw-r-----. Who can read it in the basic owner/group/other model, and what important caveat remains?
3. A long-running command is interrupted with Ctrl+C. Can you conclude it made no changes? Why not?
4. Why is /proc/<pid>/... not just an ordinary saved file?

Answers#

1. The first is absolute. The second is relative and resolves to the same path only when the current directory is /home/learner.
2. Owner and group can read it; others have no listed permissions. ACLs, mount options, capabilities, and policy can add controls.
3. No. It may have changed data before receiving the signal, and signal handling varies.
4. /proc is a virtual filesystem exposing generated kernel/process views; contents vary and are not ordinary persistent file contents.

Checkpoint#

Artifact: annotate one ls -l row (if available) or the sample mode above, and write one sentence distinguishing host process from Android device process. Ready: your explanation covers owner/group/other, exit status, and why Ctrl+C is not rollback. Revise: revisit “Paths and files” or “A process is a running program.” Not yet evidenced: you cannot tell host from device or think a permission bit guarantees access; use ADB & a safe lab later to compare context, but do not run device commands yet.

Sources#

• Linux chmod(1) — permission mode syntax and behavior; does not cover every ACL/policy layer.
• Linux proc filesystem documentation — kernel documentation for the virtual proc filesystem.
• Linux process and signal overview — signal concepts and default actions; individual programs may handle signals.
• Linux path resolution — symbolic-link resolution starts from the link's containing directory.
• credentials(7) — real and effective user/group IDs.
• pthreads(7) — threads in one process share global memory, while each has its own stack.
• stdin(3) — standard streams and descriptors 0, 1, and 2 at startup.
• Android app sandbox — Android-specific application isolation, beyond the general Linux model.

Next: C/C++ source reading.