# Permission

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/permission

## Quick definition

Permissions control who can do what with a file, folder, or network resource. Think of them as rules that say yes or no to actions like reading, writing, or deleting. Without the right permission, you get an access denied error.

## Simple meaning

Imagine you are renting a storage unit. The storage company gives you a key that only opens your unit. Other people have keys that only open their own units. Now suppose you want to let a friend store a box in your unit. You might give them a copy of your key, or you could give them a special pass that only works from 9 to 5. In the computer world, permissions work the same way. A permission is like a digital key or a rule that says who can open a file, who can change it, and who can delete it.

Every file and folder in a computer has a list of permissions attached to it. That list includes users (like you and your friend) and groups (like "everyone in the marketing team"), and for each user or group there is a set of allowed actions. Common actions include read (look at the file), write (change the file), and execute (run the file as a program). If you do not have the read permission for a document, the computer will simply refuse to open it, just like a locked door.

Permissions also exist for network resources. When you connect to a shared folder on a company server, the server checks your credentials (who you are) against its permission list. If you are not on the list, you get an error. This system keeps data safe from unauthorized access, whether that is a curious coworker or a malicious hacker. The same idea applies to printers, databases, cloud storage, and even apps on your phone. Whenever you see a pop-up asking "Allow this app to access your camera?" that is a permission request.

Understanding permissions is crucial because a small mistake can lock everyone out of a critical file or accidentally expose sensitive data to the whole company. It is one of the most fundamental concepts in IT security and administration.

## Technical definition

In computing, a permission is a rule that associates an access right with a specific subject (user, group, or system process) on a specific object (file, directory, registry key, network share, or other resource). Permissions are enforced by the operating system or application to implement access control. The two dominant models are discretionary access control (DAC) and mandatory access control (MAC). In DAC, the owner of a resource can grant or revoke permissions to others. In MAC, a central authority sets permissions based on security labels and the user cannot override them. Most general-purpose operating systems like Windows and Linux use DAC for everyday file systems, while MAC is common in high-security environments like military systems.

On Windows, permissions are managed through the New Technology File System (NTFS) security descriptors. Each security descriptor contains a discretionary access control list (DACL) and a system access control list (SACL). The DACL lists access control entries (ACEs), each specifying a trustee (user or group) and the allowed or denied access rights (e.g., Read, Write, Modify, Full Control). When a user tries to access an object, the system walks the DACL in order. If a deny entry matches the user, access is denied immediately. If an allow entry matches, that right is granted. If no entry matches, the right is implicitly denied. This order makes deny entries more powerful than allow entries, which is a common source of confusion.

On Linux and Unix-like systems, permissions are modeled around three categories: owner, group, and others. Each file has three sets of three bits: read (r), write (w), and execute (x). The owner is the user who created the file. The group is a collection of users. Others are everyone else. These bits are combined into a three-digit octal number (e.g., 755 means owner has rwx, group has r-x, others have r-x). Modern Linux systems also support access control lists (ACLs) using the setfacl and getfacl commands, which allow more granular permissions similar to Windows ACEs.

Beyond file systems, permissions are central to network security. For example, Active Directory uses group policy and NTFS permissions together to control access across a domain. In cloud environments like AWS, permissions are defined by IAM policies that are JSON documents specifying allowed or denied actions on resources. The concept also applies to database systems, where users are granted SELECT, INSERT, UPDATE, DELETE privileges on tables. In programming, permission checks are embedded in code to enforce user roles.

Permissions are also critical in user account control (UAC) on Windows, where a standard user must elevate to an administrator to perform system-level changes. On mobile operating systems, apps request permissions at runtime (e.g., location, camera) via the OS permission manager. Failure to properly configure permissions leads to security vulnerabilities such as privilege escalation, data leakage, or denial of service. Understanding the principle of least privilege, giving users only the permissions they absolutely need, is a foundational security practice.

## Real-life example

Think of a shared office kitchen. The kitchen has a coffee machine, a fridge, and a cabinet with snacks. The office manager wants to make sure that only certain people can use certain things. So they create rules. Everyone in the office can use the coffee machine (read permission), but only the designated coffee captain can refill the water and beans (write permission). The fridge is open to anyone for storing their lunch, but only the cleaning crew can throw away old food that has been there for weeks (delete permission). The snack cabinet is locked and only senior staff have a key (execute permission after authentication).

Now, one day a new intern starts. The office manager gives the intern a keycard that allows them to open the main door and use the coffee machine. But the intern does not have the snack cabinet key. The intern tries the cabinet, it does not open. No big deal. But what if the intern also cannot open the fridge? They would not be able to store their lunch. That would be a problem. So the manager updates the permissions for the intern to include fridge access.

In the computer world, the coffee machine is a shared folder on the network. The coffee captain is the user who has write permission to modify files in that folder. The snack cabinet is a restricted folder with sensitive data. The intern's keycard is their user account. The manager's rules are the access control entries on the folder's security descriptor. When the intern tries to open the restricted folder, the operating system checks the intern's user ID against the permission list, sees no match, and denies access, exactly like the locked cabinet door.

This analogy also illustrates inheritance. If the kitchen had a rule that all offices on the third floor can automatically access the fridge, that is like a parent folder's permissions being inherited by subfolders. Changing the rule at the kitchen level (parent) affects all items inside (children). This saves the manager from having to set permissions on every single container of yogurt individually.

## Why it matters

Permissions are the foundation of security and data integrity in any IT environment. Without permissions, anyone could read, change, or delete any file on a system. That would mean a student could accidentally delete the payroll database, or a malicious insider could steal customer credit card numbers. In a business context, permissions ensure that only authorized personnel can access sensitive information like human resources records, financial data, or intellectual property.

From an IT administration perspective, permissions directly impact daily operations. When a new employee joins, the IT team must grant the appropriate permissions to network shares, email, internal applications, and databases. If they give too many permissions, the company risks data breaches. If they give too few, the employee cannot do their job and productivity suffers. This balancing act is called the principle of least privilege, and it is a core concept in security certifications like CompTIA Security+ and CISSP.

Permissions also affect system reliability. Setting incorrect permissions on system files can cause software to crash, services to fail to start, or the operating system to become unbootable. For example, if the read permission is accidentally removed from a critical DLL file, every program that needs that DLL will stop working. In shared hosting environments, incorrect folder permissions can allow one user to read another user's website code, leading to data theft or defacement.

In cloud and virtualized environments, permissions control not only data but also the ability to create, modify, or delete infrastructure resources like virtual machines, databases, and network security groups. A misconfigured permission can allow a developer to accidentally spin up a million-dollar GPU instance or expose a storage bucket to the entire internet. Real-world breaches, such as the 2019 Capital One data breach, were caused by overly permissive IAM roles. Understanding permissions is not just an academic exercise, it is a critical skill for preventing costly security incidents.

## Why it matters in exams

Permissions are a high-frequency topic across many IT certification exams, especially at the entry and intermediate levels. In CompTIA A+ (220-1102), you need to understand how to configure file permissions in Windows (NTFS) and Linux (chmod, chown). You will see questions about the difference between share permissions and NTFS permissions, and the effective permission when both are applied. In CompTIA Network+, you might encounter questions about access control lists (ACLs) on routers and switches, which are essentially permissions for network traffic. In CompTIA Security+, permissions fall under access control models (DAC, MAC, RBAC) and the principle of least privilege. You should know how to interpret permission strings in Linux (e.g., drwxr-xr-x) and understand the sticky bit, SUID, and SGID.

For Microsoft exams like MS-900 (Microsoft 365 Fundamentals) and AZ-900 (Azure Fundamentals), you need to understand Azure RBAC (role-based access control) and how permissions are assigned via built-in roles like Contributor, Reader, and Owner. Questions often present a scenario where a user cannot perform an action, and you must identify whether the issue is a permission problem (denied access) or something else. In AWS Certified Cloud Practitioner, you need to understand IAM policies and how they grant or deny permissions to users, groups, and roles. The concept of "explicit deny overrides allow" is a common exam trap.

In more advanced exams like CISSP, permissions are covered in the access control domain. You must understand different access control models (DAC, MAC, RBAC, ABAC) and be able to select the appropriate model for a given scenario. Exam questions may present a complex permission configuration and ask you to determine the effective access for a user who is a member of multiple groups. The key is to remember that deny entries typically take precedence over allow entries, and that the most restrictive effective permission applies when combining share and NTFS permissions.

In Linux Professional Institute (LPIC) exams, you must be able to read and change permissions numerically (777, 644, etc.) and using symbolic mode (u+rwx, g+rx, o-rwx). You also need to understand ACLs and the setfacl command. The exams often include a fill-in-the-blank or multiple-choice question where you have to determine the correct command to grant specific permissions. The best way to prepare is to practice on a live Linux system or Windows VM, creating users and groups and testing permissions to see the effects. Understanding permissions deeply will serve you well across multiple certification paths.

## How it appears in exam questions

Exam questions about permissions appear in several distinct patterns. The first pattern is the scenario question: "A user reports that they cannot save a file to a shared folder. What should you check first?" The answer usually points to NTFS or share permissions. You need to distinguish between the two: share permissions only apply when accessing the resource over the network; NTFS permissions apply both locally and over the network. The effective permission is the most restrictive of the two. For example, if share permission is Full Control but NTFS permission is Read, the effective permission is Read.

The second pattern is the configuration question: "Which command sets the permissions on a file to owner read/write/execute, group read/execute, and others no access?" On Linux, that is chmod 750 filename. On Windows, it might involve using icacls or the GUI. These questions test your memory of octal values (4=read, 2=write, 1=execute) and the order of user/group/others.

The third pattern is the troubleshooting question, often involving a user who belongs to multiple groups with conflicting permissions. For instance, a user is a member of Group A with Allow Read and Group B with Deny Write. The user tries to write to a file. Since Deny entries override Allow entries, write is denied. Understanding this hierarchy is critical.

The fourth pattern is the comparison question: "What is the difference between an access control entry (ACE) and an access control list (ACL)?" The ACL is the entire list of ACEs. The ACE is a single entry granting or denying a specific right. You might also see questions about inheritance: "If you move a file from one folder to another, does it inherit the permissions of the destination folder?" On Windows NTFS, moving a file within the same volume preserves its original permissions, but moving it to a different volume causes it to inherit the destination's permissions.

On cloud exams, you might see a question like: "A developer needs to allow a Lambda function to write logs to CloudWatch. Which IAM action should be allowed?" The answer is something like logs:CreateLogStream and logs:PutLogEvents. These questions test your ability to map real-world actions to specific permission names. In AWS, the IAM policy simulator is a useful tool to validate these scenarios.

Finally, there are trick questions about the effective permissions when inheritance is blocked. For example, a parent folder has Allow Write for Everyone, but a subfolder has inheritance disabled and no explicit permissions. The member of Everyone will have no access to that subfolder because no explicit allow entry exists. Always remember: no explicit allow means implicit deny.

## Example scenario

A small company called GreenLeaf Books has a network shared folder called "StaffDocs" on a Windows server. The folder contains subfolders: "Public", "HR_Only", and "Marketing_Plans". The HR manager, Sarah, needs to add a new employee named Tom. Tom's job is in the marketing department. Sarah calls the IT help desk and says, "I need Tom to have access to the Public folder and the Marketing_Plans folder, but not the HR_Only folder."

The IT technician, Alex, creates a user account for Tom. Then Alex navigates to the "StaffDocs" share. He sets share permissions to "Everyone: Read" because all staff should at least be able to see the folder structure. Then Alex goes into NTFS permissions. The "Public" folder already has the "Domain Users" group with Allow Read and Allow Write. Since Tom is a domain user, he will automatically have those permissions. For the "Marketing_Plans" folder, Alex creates a security group called "MarketingTeam" and adds Tom to that group. He gives the MarketingTeam group Allow Modify permission on that folder. For the "HR_Only" folder, Alex ensures that only the "HRTeam" group has Allow Read permissions. Tom is not a member of HRTeam, so he cannot even see the folder contents.

Now, Tom logs into his workstation and double-clicks the "StaffDocs" share. He can see all three folders. He opens the "Public" folder and can read and save files, good. He opens the "Marketing_Plans" folder and can read, add, and modify files, exactly as intended. He double-clicks the "HR_Only" folder, and gets an "Access Denied" message. This is correct.

But what if Tom calls the help desk saying he cannot save a file to the "Marketing_Plans" folder? Alex would first check the effective permissions: Tom is in MarketingTeam with Allow Modify, but maybe there is also a Deny Write entry on the folder for the "Everyone" group. In that case, the Deny would override the Allow, causing the problem. Alex would see that the Deny entry was inherited from the parent "StaffDocs" folder, but was intended only for the "HR_Only" folder. The fix would be to either remove the Deny entry from "Marketing_Plans" or block inheritance and apply explicit allows. This scenario shows how a single misconfigured permission can disrupt work, and how systematic troubleshooting resolves it.

## Common mistakes

- **Mistake:** Assuming that share permissions and NTFS permissions are the same thing.
  - Why it is wrong: Share permissions only apply when you access a folder over the network. NTFS permissions apply whether you access the folder locally or over the network. The effective permission is the most restrictive of the two. Many learners forget this and give a user Full Control share permission but Read NTFS permission, then wonder why the user cannot write.
  - Fix: Always check both share and NTFS permissions. To allow write access over the network, ensure that both share and NTFS permissions grant write.
- **Mistake:** Thinking that Windows 'Allow' entries always give you access, even when a 'Deny' entry exists.
  - Why it is wrong: In Windows, explicit Deny entries override Allow entries. If a user is in one group that has Deny Write and another group that has Allow Write, the user cannot write.
  - Fix: Use Deny sparingly. Prefer to grant permissions only to the necessary users/groups rather than granting all and then denying a few. If you must use Deny, remember that it overrides everything.
- **Mistake:** Using 777 permissions on Linux for convenience.
  - Why it is wrong: 777 gives read, write, and execute to everyone, including users who have no business modifying the file. This is a major security risk. It can allow anyone to replace a script with malicious code.
  - Fix: Use the principle of least privilege. If a file only needs to be read by everyone, use 644 (owner read/write, everyone else read). Only grant write and execute to the minimum necessary users.
- **Mistake:** Confusing file permissions with file ownership on Linux.
  - Why it is wrong: Permissions control what you can do with a file, but ownership determines who can change the permissions. A user can only change permissions of files they own (unless they are root). Many beginners think that if they have write permission, they can also change the permission bits.
  - Fix: Remember: To change permissions (chmod), you must be the file owner or root. Write permission just allows you to modify the content of the file, not its metadata.
- **Mistake:** Ignoring permission inheritance in Windows when moving files between folders.
  - Why it is wrong: On the same volume, moving a file preserves its original permissions, but many expect it to inherit the destination folder's permissions. This can result in unintended access or denial of access.
  - Fix: After moving a file, always verify its effective permissions. If you want it to inherit the destination's permissions, either copy instead of move (copying creates a new file that inherits), or manually reset permissions after moving.

## Exam trap

{"trap":"A question presents a user who belongs to Group A with Allow Read and Group B with Deny Read on the same file. It asks what the user's effective access is. The trap is that learners often think the Allow entry should give read access because the user is a member of Group A.","why_learners_choose_it":"Learners may think that having an Allow entry from any group is sufficient. They might also be confused by the order of ACEs or think that the first matching rule applies.","how_to_avoid_it":"Remember that in Windows NTFS permissions, explicit Deny entries take precedence over explicit Allow entries, regardless of the order. The effective read access is Denied. In some other systems like Linux ACLs, the order does matter, but for the CompTIA and Microsoft exams, the key rule is: Deny overrides Allow."}

## Commonly confused with

- **Permission vs Privilege:** A privilege is a right to perform a system-level action, such as shutting down the server or changing system time, which is not tied to a specific file or object. A permission is tied to a specific resource like a file or printer. For example, a user may have permission to read a printer queue but not the privilege to install a new printer driver. (Example: A hotel guest has permission to enter their room (like file read), but they do not have the privilege to change the hotel's master key system.)
- **Permission vs Access Control List (ACL):** An ACL is the entire list of rules (called ACEs) that define permissions for an object. A permission is a single rule within that list. So the ACL is the container, and each permission is an entry in that container. (Example: A club's guest list (ACL) contains multiple names (permissions). Being on the list means you have permission to enter, but the list itself is not the permission.)
- **Permission vs Right (as in user right):** User rights are system-wide capabilities like 'log on locally' or 'shut down the system', assigned through Group Policy or local security policy. Permissions are object-specific. A user might have the right to log on interactively but still be denied permission to open a specific file. (Example: A security guard has the right to be inside the building (user right), but not the permission to open the CEO's office safe.)
- **Permission vs Role:** A role is a collection of permissions grouped together under a job function, often used in role-based access control (RBAC). A permission is a single atomic action. For example, the role 'Editor' might include permissions to read, write, and delete articles, but not to manage users. (Example: In a library, the role 'Librarian' includes the permissions to check out books, add new books, and update records. A single permission might be just 'check out books'.)

## Step-by-step breakdown

1. **Subject Request** — A user or system process (the subject) initiates a request to access an object, such as opening a file, writing to a folder, or connecting to a printer. The operating system intercepts this request before granting access.
2. **Authentication Verification** — The system identifies the subject by verifying their credentials, such as a username and password, or a security token. Without proper authentication, no permissions are evaluated, access is denied automatically.
3. **Object Security Descriptor Retrieval** — Each securable object (file, folder, registry key) has a security descriptor stored in the filesystem. The system retrieves this descriptor, which contains the owner SID, the DACL (discretionary access control list), and the SACL (system audit control list).
4. **DACL Evaluation Order** — The system reads the DACL, which is a list of access control entries (ACEs). Each ACE specifies a trustee (user or group) and the type of access (Allow or Deny) with specific rights. The system evaluates the ACEs in order, but follows the rule that Deny ACEs are evaluated first and always take precedence.
5. **Permission Match and Decision** — If the system finds a Deny ACE that matches the subject and includes the requested right, it immediately denies access and stops evaluation. If it finds an Allow ACE that matches, it grants that right. If the DACL has no entries (null DACL), the behavior depends on the system, but in Windows, it means no access by default. If the DACL is empty (empty DACL), all access is denied.
6. **Access Grant or Error** — Based on the evaluation, the system either allows the subject to perform the action (e.g., read from the file) or returns an access denied error (e.g., error 5 in Windows). The subject never sees the permission rules, only the result.
7. **Audit Logging (Optional)** — If auditing is configured via the SACL, the system generates an audit event recording whether the access was granted or denied. This is used by security teams to monitor unauthorized access attempts.

## Practical mini-lesson

Permissions are something you will configure almost every day as an IT professional. The best way to master them is to practice on a real system. Set up a Windows VM with two local users and a shared folder. Try the following: create a folder, give User1 Allow Read and User2 Allow Full Control via NTFS permissions. Now set the share permissions to Everyone: Read. Log in as User2 over the network and try to create a file. You will get an access denied error because share permissions restrict write even though NTFS allows it. That is the most restrictive permission rule in action.

On Linux, practice with chmod in a sandbox directory. Create a file, then run 'ls -l' to see its permissions. Change permissions using octal notation: chmod 644 myfile.txt. Then try to write to the file as another user. You will see the permission denied message. Then use chown to change the file owner. Note that only root or the owner can change permissions.

A common real-world task is granting a user access to a folder that is nested several levels deep. Suppose a user needs write access to \\server\data\projects\2025\budget\. The permissions on 'data' might be inherited by all subfolders. If you grant the user permission on 'budget', they might still not be able to traverse 'projects' if the 'projects' folder lacks the 'List Folder Contents' permission for that user. This is why you should always check effective permissions in Windows by right-clicking the folder, going to Security > Advanced > Effective Access, and typing the user's name. This shows what the user can actually do.

Another real-world scenario is fixing a broken application. An application installs a service that runs as a local system account. The service needs to write logs to a folder. If the folder permissions are set to only allow Administrators to write, the service will fail. The fix is to grant the necessary permission to the service account (e.g., NT AUTHORITY\SYSTEM or a specific managed service account). Always run applications with the least privilege needed, but no less.

In cloud environments, you will write IAM policies. Permissions are granted through JSON statements with Effect (Allow or Deny), Action (like s3:GetObject), Resource (like arn:aws:s3:::bucket/*), and Condition (like IP address range). A common mistake is forgetting the implicit deny. If a policy does not explicitly allow an action, it is denied. An explicit Deny overrides any Allow. For example, if you write a policy that allows s3:GetObject but also has a separate Deny for a specific bucket, the Deny wins.

Troubleshooting permission issues is a core skill. Always start by confirming the user is who they say they are (authentication). Then check the permissions at the object level. Use the principle of least privilege to avoid overcomplicating your permission structure. Document every permission change you make.

## Memory tip

Remember 'DENY overrides ALLOW' in Windows, Deny Always Wins.

## FAQ

**What is the difference between share permissions and NTFS permissions?**

Share permissions apply only when a folder is accessed over the network. NTFS permissions apply both locally and over the network. The effective permission is the most restrictive of the two.

**Why can't I change a file's permissions even though I am the owner?**

On Linux, you might need to use sudo if you are not root. On Windows, you may need to take ownership first if another user has changed the owner.

**What does 'chmod 777' do, and why is it dangerous?**

It gives read, write, and execute permissions to everyone (owner, group, and others). It is dangerous because it allows any user on the system to modify the file, which could lead to data loss or security breaches.

**How do I check effective permissions for a user in Windows?**

Right-click the folder or file, go to Properties > Security > Advanced > Effective Access, then type the user's name and click 'View effective access'.

**What is an ACL in relation to permissions?**

An ACL (Access Control List) is a list of ACEs (Access Control Entries) attached to an object. Each ACE is an individual permission that allows or denies a specific user or group a specific right.

**Can a user with Read permission also delete a file?**

Not directly. Deleting a file requires either the Modify or Full Control permission, or the Delete permission specifically. However, if a user has the Write permission on a folder, they can delete files inside it if they have the appropriate folder-level delete permission.

**Do permissions apply to backups?**

It depends. A backup application running as an administrator or system account can usually read any file regardless of permissions. When the backup is restored, the original permissions are typically restored along with the files.

## Summary

Permissions are the rules that control who can do what with digital resources like files, folders, printers, and network shares. They are a fundamental part of operating system security and data protection. Without permissions, anyone could read, modify, or delete any data, making the system completely insecure. Permissions work by attaching an access control list (ACL) to every securable object, with entries that either allow or deny specific actions for specific users or groups.

Understanding permissions is essential for IT professionals because misconfigurations are one of the most common causes of both security breaches and user frustration. The principle of least privilege, giving users only the permissions they absolutely need, is a best practice that reduces risk. On Windows, you must distinguish between share permissions and NTFS permissions, and remember that explicit deny entries override all allow entries. On Linux, you need to be comfortable with octal notation and ownership concepts.

In certification exams, permissions appear in scenario-based questions, configuration questions, and troubleshooting scenarios. You will need to know how to set permissions, how to interpret existing permission strings, and how to resolve access denied errors. Whether you are taking CompTIA A+, Network+, Security+, Microsoft Azure, AWS, or Linux exams, a solid grasp of permissions will help you answer questions correctly and perform your job more effectively. Practice with real systems to build muscle memory, and always verify permissions with tools like effective access (Windows) or ls -l (Linux).

The key exam takeaway is: permissions are about granular control over resources. Always consider the effective permission, respect the deny override principle, and default to denying access unless explicitly needed. Add this topic to your study checklist and review it until it becomes second nature.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/permission