Unit 4: File Permissions and Ownership - Subjective Questions

The Linux Permission Model is a security mechanism that controls access to files and directories. It defines who can access a file and what actions they can perform.

Three Categories of Users (Classes):

• Owner (User - u): The user who created the file. Usually has the most control.
• Group (g): A set of users who share the same permissions. Every file belongs to a group.
• Others (o): All other users on the system who are neither the owner nor part of the group.

Three Types of Permissions:

• Read (r): Permission to view the contents of a file or list a directory.
• Write (w): Permission to modify a file or add/remove files in a directory.
• Execute (x): Permission to run a file as a program or enter (cd into) a directory.

Representation: Permissions are displayed as a 10-character string, e.g., -rwxr-xr--:

• 1st character: file type (- for regular file, d for directory).
• Next 3: owner permissions (rwx).
• Next 3: group permissions (r-x).
• Last 3: others permissions (r--).

This model ensures confidentiality, integrity, and controlled access to system resources.

The three basic permissions have different implications depending on whether they apply to a file or a directory.

For Files:

• Read (r): Allows viewing/opening the contents of the file (e.g., using cat, less).
• Write (w): Allows modifying or overwriting the file's content.
• Execute (x): Allows running the file as a program or script.

For Directories:

• Read (r): Allows listing the names of files inside the directory (e.g., ls).
• Write (w): Allows creating, deleting, or renaming files within the directory (requires x as well).
• Execute (x): Allows entering the directory (cd) and accessing files inside it.

Key Points:

• A directory needs both r and x for full listing and access.
• Write permission on a directory allows deleting files even if you don't own them (unless the sticky bit is set).
• Execute alone on a directory allows access to a known filename but not listing.

The chmod (change mode) command in symbolic mode uses letters and operators to modify permissions in a human-readable way.

Syntax: chmod [who][operator][permission] file

Who (User Classes):

• u = user/owner
• g = group
• o = others
• a = all (u+g+o)

Operators:

• + : Add permission
• - : Remove permission
• = : Set exact permission

Permissions: r (read), w (write), x (execute)

Examples:

• chmod u+x file.sh → Adds execute permission for the owner.
• chmod go-w file.txt → Removes write permission from group and others.
• chmod a=r file.txt → Sets read-only for everyone.
• chmod u+rwx,g+rx,o+r file → Combines multiple settings.

Advantages: Symbolic mode is intuitive and allows modifying specific permission bits without affecting others.

In Numeric (Octal) Mode, permissions are represented by numbers based on the sum of permission values.

Permission Values:

• Read (r) =
• Write (w) =
• Execute (x) =
• No permission =

Calculation: Add values for each user class (owner, group, others) to form a 3-digit octal number.

Common Examples:

• chmod 755 file → Owner: (rwx), Group: (r-x), Others: (r-x).
• chmod 644 file → Owner: (rw-), Group: (r--), Others: (r--).
• chmod 700 file → Owner: (rwx), Group: (---), Others: (---).
• chmod 777 file → Full permissions for everyone (rwxrwxrwx).

Conversion Example: For rwxr-xr--:

• Owner rwx =
• Group r-x =
• Others r-- =
• Result = 754

Advantage: Numeric mode is concise and sets all permission bits at once.

Symbolic Mode vs Numeric Mode of chmod:

Advantages of Symbolic Mode:

• Easy to add/remove a single permission.
• Self-explanatory syntax.

Disadvantages of Symbolic Mode:

• Verbose for setting all permissions.

Advantages of Numeric Mode:

• Quick and concise.
• Guarantees exact permission state.

Disadvantages of Numeric Mode:

• Requires understanding of octal calculation.
• Overwrites existing permissions entirely.

Conclusion: Use symbolic mode for partial changes and numeric mode for complete permission assignment.

The chown (change owner) command is used to change the user owner and/or group owner of a file or directory. It is typically executed by the root user or with sudo.

Syntax: chown [options] user[:group] file

Examples:

• chown alice file.txt → Changes the owner to alice.
• chown alice:developers file.txt → Changes owner to alice and group to developers.
• chown :developers file.txt → Changes only the group to developers.
• chown -R alice /home/project → Recursively changes ownership of a directory and all its contents.

Common Options:

• -R : Recursive (applies to all files/subdirectories).
• -v : Verbose (shows what changed).

Use Case: When files are moved between users or transferred to a project team, chown reassigns proper ownership so that permission rules apply correctly.

Note: Only the superuser can change the owner of a file; a regular user cannot give away their files.

File Ownership refers to the association of every file and directory with a specific user and group in Linux.

Types of Ownership:

• User Ownership (Owner): The user who created the file. The owner has the primary control and can typically change permissions.
• Group Ownership: Every file belongs to a group. All members of that group share the group-level permissions defined for the file.

Viewing Ownership: The ls -l command shows ownership:

-rw-r--r-- 1 alice developers 2048 Sep 25 file.txt

Here alice is the owner and developers is the group.

Importance for Security:

• Access Control: Ownership determines which permission set (owner/group/others) applies to a user.
• Data Protection: Prevents unauthorized users from modifying files.
• Accountability: Tracks which user is responsible for a file.
• Privilege Separation: Combined with permissions, ownership enforces the principle of least privilege.

Related Commands:

• chown → change ownership.
• chgrp → change group ownership.

The umask (user mask) command sets the default permissions that are removed from newly created files and directories. It acts as a filter that masks out certain permission bits.

Base (Maximum) Permissions:

• Files: (rw-rw-rw-) — files are not executable by default.
• Directories: (rwxrwxrwx).

Calculation: Default permission = Base Permission umask

Formula:

Example (umask = 022):

• Files: (rw-r--r--)
• Directories: (rwxr-xr-x)

Example (umask = 077):

• Files: (rw-------)
• Directories: (rwx------)

Usage:

• umask → displays current mask.
• umask 027 → sets a new mask.

Significance: A well-chosen umask enhances security by restricting default access to newly created files.

The permission string drwxr-x--- can be broken down as follows:

Character-by-character analysis:

• d → It is a directory.
• rwx (Owner) → Owner can read, write, and execute (enter) the directory.
• r-x (Group) → Group members can read (list) and execute (enter) but cannot write.
• --- (Others) → Others have no permissions at all.

Numeric (Octal) Conversion:

• Owner:
• Group:
• Others:

Octal Value = 750

Meaning: This is a common secure setting where the owner has full control, the group can access and list contents, and all other users are completely denied access. This is often used for private project directories shared within a team.

Permission Security Concepts are guidelines to keep a Linux system secure through proper permission management.

1. Principle of Least Privilege:

• Grant only the minimum permissions required for a user or process to perform its task.
• Reduces the attack surface and limits potential damage.

2. Dangers of 777 (rwxrwxrwx):

• Grants full access to everyone, allowing any user to read, modify, or execute the file.
• Can lead to data corruption, malware injection, and privilege escalation.
• Should be avoided, especially for scripts and configuration files.

3. Best Practices:

• Use 644 for regular files and 755 for directories/scripts.
• Never give write permission to others on sensitive files.
• Set a restrictive umask (e.g., 027) for privacy.
• Use group ownership to share files securely within a team.
• Regularly audit permissions of important system files.
• Protect sensitive files (e.g., private keys) with 600.

4. Special Considerations:

• Avoid running programs as root unless necessary.
• Use the sticky bit on shared directories to prevent deletion of others' files.

Conclusion: Proper permissions form the foundation of Linux security by ensuring confidentiality, integrity, and controlled access.

These three commands manage different aspects of file access control in Linux.

1. chmod (change mode):

• Modifies read/write/execute permissions.
• Example: chmod u+x script.sh adds execute for owner.

2. chown (change owner):

• Reassigns the file's owner and/or group.
• Requires root privileges.
• Example: chown bob file.txt makes bob the owner.

3. chgrp (change group):

• Changes only the group associated with a file.
• Example: chgrp developers project/ assigns the file to the developers group.

Summary: chmod controls what can be done, while chown and chgrp control who owns the file. Together they define the complete access control policy.

We need to compute default permissions using the umask filter.

Given:

• File base permission = (rw-rw-rw-)
• Directory base permission = (rwxrwxrwx)
• umask =

Method: The umask bits are subtracted (masked out) from the base permissions. The precise operation is a bitwise AND with the complement of the umask.

Step 1: Convert umask 027 to binary permission removal

• → removes nothing from owner.
• → removes write () from group.
• → removes read, write, execute from others.

Step 2: Calculate File Permissions (Base 666):

• Owner: (rw-)
• Group: (r--)
• Others: (cannot go below 0; execute bit wasn't there) → (---)
• Result = 640 (rw-r-----)

Step 3: Calculate Directory Permissions (Base 777):

• Owner: (rwx)
• Group: (r-x)
• Others: (---)
• Result = 750 (rwxr-x---)

Final Answer:

• File:
• Directory:

Beyond the standard rwx permissions, Linux provides three special permission bits for advanced access control.

1. SetUID (Set User ID) — value 4 (4000):

• When set on an executable file, the program runs with the owner's privileges rather than the user who runs it.
• Example: /usr/bin/passwd uses SetUID so users can update passwords stored in root-owned files.
• Set with: chmod u+s file or chmod 4755 file.
• Shown as an s in the owner's execute position: -rwsr-xr-x.

2. SetGID (Set Group ID) — value 2 (2000):

• On a file: runs with the group's privileges.
• On a directory: new files created inside inherit the directory's group.
• Set with: chmod g+s dir or chmod 2755 dir.
• Shown as s in the group's execute position: -rwxr-sr-x.

3. Sticky Bit — value 1 (1000):

• Applied to directories, it ensures that only the file owner (or root) can delete or rename files, even if others have write access.
• Example: /tmp directory uses the sticky bit.
• Set with: chmod +t dir or chmod 1777 dir.
• Shown as t in the others' execute position: drwxrwxrwt.

Numeric Usage: These are prefixed as a 4th octal digit, e.g., chmod 4755, chmod 2755, chmod 1777.

The ls -l command lists files in long format, displaying detailed information including permissions and ownership.

Example Output:

-rwxr-xr-- 1 alice developers 4096 Sep 25 10:30 report.sh

Field-by-Field Interpretation:

1. -rwxr-xr-- → File type + Permissions
   • - = regular file (d = directory, l = link).
   • rwx = owner permissions.
   • r-x = group permissions.
   • r-- = others permissions.
2. 1 → Number of hard links to the file.
3. alice → Owner (user) of the file.
4. developers → Group owner of the file.
5. 4096 → File size in bytes.
6. Sep 25 10:30 → Last modified date and time.
7. report.sh → File name.

Key Insight: By reading this line, an administrator can immediately determine who owns a file, which group it belongs to, and what actions each user class can perform — essential for security auditing.

Problem: The owner cannot execute their own script deploy.sh.

Possible Causes:

1. Missing Execute Permission:

• Even the owner needs the execute (x) bit to run a script.
• Check with ls -l deploy.sh. If it shows -rw-r--r--, execute is missing.
• Fix: chmod u+x deploy.sh or chmod 755 deploy.sh.

2. Directory Execute Permission Missing:

• To access the file, the user needs execute permission on the containing directory.
• Fix: chmod u+x /path/to/directory.

3. Ownership Mismatch:

• If the file is not actually owned by the user, owner permissions won't apply.
• Verify with ls -l and fix with chown user deploy.sh (needs root).

4. Filesystem Mounted with noexec:

• Some partitions are mounted with the noexec option, blocking execution.
• Fix: Move the script to an executable partition or remount.

5. Incorrect Shebang:

• Missing or wrong #!/bin/bash line can cause failures.

Recommended Solution:
bash
chmod u+x deploy.sh
./deploy.sh

Conclusion: The most common cause is a missing execute bit, easily fixed with chmod u+x.

Linux uses different base (maximum) permissions for files and directories, and this difference is intentional for security reasons.

Base Permissions:

• Files: (rw-rw-rw-) — no execute bit.
• Directories: (rwxrwxrwx) — includes execute.

Reasoning for Files (No Execute by Default):

• Most newly created files are data files (text, documents, configs), not programs.
• Automatically making every new file executable would be a serious security risk — a malicious or accidental file could be run as a program.
• Users must explicitly grant execute permission (chmod +x) when a file is genuinely a script or binary. This enforces conscious decision-making.

Reasoning for Directories (Execute Included):

• For directories, the execute bit means the ability to enter/traverse the directory (cd) and access its contents.
• Without execute, a directory would be almost useless — you couldn't access files inside it.
• Hence directories need the execute bit by default.

Security Principle:
This design reflects the principle of least privilege — grant only the permissions genuinely needed. Files get executable status only when explicitly required, minimizing the risk of unintended code execution.

(a) Recursive Permission Change using chmod -R:

• The -R (recursive) option applies permission changes to a directory and all its contents (subdirectories and files).
• Example: chmod -R 755 /var/www sets permissions for the entire web directory tree.
• Caution: Recursive changes can be dangerous if applied incorrectly, as they affect many files at once. It's often better to use find to apply different permissions to files vs directories:
  bash
  find /path -type d -exec chmod 755 {} \;
  find /path -type f -exec chmod 644 {} \;

(b) Role of the Root User:

• The root (superuser) has UID 0 and bypasses all permission checks.
• Root can read, write, and execute any file regardless of its permission bits.
• Only root can use chown to change file ownership.
• Because of its unlimited power, root access must be used carefully to avoid accidental system damage.

(c) Primary vs Secondary Group:

• Primary Group: The default group assigned to a user; new files created by the user belong to this group. Defined in /etc/passwd.
• Secondary (Supplementary) Groups: Additional groups a user belongs to, granting extra access. Defined in /etc/group.
• Example: A user's primary group may be staff while also being a secondary member of developers and admins.

(i) Convert rw-r--r-- to Octal:

• Owner: rw- =
• Group: r-- =
• Others: r-- =
• Octal = 644

(ii) Convert Octal 640 to Symbolic:

• (Owner) = $4+2 = $ rw-
• (Group) = $4 = $ r--
• (Others) = ---
• Symbolic = rw-r-----

(iii) chmod 754 in Symbolic Representation:

• (Owner) = $4+2+1 = $ rwx
• (Group) = $4+1 = $ r-x
• (Others) = $4 = $ r--
• Symbolic = rwxr-xr--
• Equivalent symbolic command: chmod u=rwx,g=rx,o=r file

Summary Table:

Relationship between Permissions, Ownership, and Security:

File permissions and ownership together form the core access control mechanism in Linux, directly impacting system security.

• Ownership determines whose rules apply (owner, group, others).
• Permissions determine what actions each class can perform.
• When combined, they enforce confidentiality (who can read), integrity (who can modify), and availability (controlled execution).

How They Work Together:

• The kernel checks the user's identity against the file's owner and group.
• The matching permission set (owner/group/others) is then applied.

Real-World Security Breach Scenario:

Scenario: An administrator sets chmod 777 on a web application's configuration file config.php that contains database credentials.

Consequences:

• Any user (or a compromised web process) can read the credentials.
• An attacker who gains limited access could modify the file to inject malicious code.
• The database could be fully compromised, leading to data theft.

Correct Approach:

• Set restrictive permissions: chmod 640 config.php.
• Assign proper ownership: chown www-data:www-data config.php.
• Apply the principle of least privilege.

Conclusion: Misconfigured permissions are among the most common causes of security breaches. Proper ownership and restrictive permissions are essential defensive measures.

Comparison of umask 022 and umask 077:

umask 022:

• Removes write permission from group and others.
• File permissions: (rw-r--r--)
• Directory permissions: (rwxr-xr-x)
• Effect: Others can read files but not modify them.

umask 077:

• Removes all permissions from group and others.
• File permissions: (rw-------)
• Directory permissions: (rwx------)
• Effect: Only the owner has any access; complete privacy.

Comparison Table:

Suitability:

• umask 022 is suitable for shared servers or systems where files (e.g., web content, shared documents) need to be readable by others. It balances collaboration and security.
• umask 077 is suitable for private systems or servers handling sensitive data (e.g., personal machines, secure hosts), ensuring maximum confidentiality.

Conclusion: Choose the umask based on the environment's balance between collaboration and confidentiality.