Operating system variations
Unix-like and otherwise POSIX-compliant systems, including Linux-based systems and all Mac OS X versions, have a simple system for managing individual file permissions, which in this article are called "traditional Unix permissions". Most of these systems also support some kind of access control lists, either proprietary (old HP-UX ACLs, for example), or POSIX.1e ACLs, based on an early POSIX draft that was abandoned, or NFSv4 ACLs, which are part of the NFSv4 standard.
Microsoft and IBM DOS variants (including MS-DOS, PC DOS, Windows 95, Windows 98, Windows 98 SE, and Windows Me) do not have permissions, only file attributes. There is a read-only attribute (R), which can be set or unset on a file by any user or program, and therefore does not prevent him/her from changing/deleting the file. There is no permission in these systems which would prevent a user from reading a file.
Special File Permissions in Linux: SUID, GUID and Sticky Bit
File permissions and ownership are the basic and yet essential security concepts in Linux. You probably are already familiar with these terms already. It typically looks like this:
Apart from these regular permissions, there are a few special file permissions and not many Linux users are aware of it:
To discuss special file permissions, let's assume you already know the basics of file permissions. For example, consider the passwd command, which is used to change a user's password. Normally, you would see x (execute) or - (no permission) in the user permissions section, but in this case, you see an s instead.
Here’s why this matters:
- Special 's' Permission: The
sstands for "setuid," which allows a user to run the file with the permissions of the file owner (in this case, the root user). - Ownership: The
passwdcommand is owned by the root user and the root group. - Why It’s Useful: With this
spermission, a regular user can run thepasswdcommand with root privileges without needingsudoaccess. This is safer and more controlled than giving full root access to the user.
What is SUID?
When the SUID (Set User ID) bit is set on an executable file, it means that the file will run with the same permissions as the file's owner, no matter who runs it. For example, consider the following command and output:
user@linux:/home/user$ ls -l /usr/bin/passwd
-rwsr-xr-x. 4 root root 91624 Jan 1 1970 /usr/bin/passwd
Here, the s in -rwsr-xr-x indicates that the SUID bit is set, so when any user runs /usr/bin/passwd, it will execute with the permissions of the root user (the owner of the file).
Any user running the passwd command will be running it with root permissions.Why is this beneficial? The passwd command needs to edit important files like /etc/passwd and /etc/shadow to change the password. These files are owned by root and can only be modified by root. But thanks to the setuid flag (SUID bit), a regular user can also modify these files to change their own password.This is why you can use the passwd command to change your own password even though the files it modifies are owned by root.
A normal user can’t change passwords for other users, only for themselves. But why? If you can run the passwd command as a regular user with the same permissions as root and modify files like /etc/passwd, why can’t you change the password of other users?
If you check the code for the passwd command, you’ll find that it checks the UID of the user whose password is being modified with the UID of the user that ran the command. If it doesn’t match and if the command wasn’t run by root, it throws an error. Below we can see an extract from the passwd checking for the UID, value:
static char *name;/* The name of user whose password is being changed */
static char *myname;/* The current user's name */
static bool amroot;/* The caller's real UID was 0 */
...[omitted].../
/*/
* The program behaves differently when executed by root than when/
* executed by a normal user./
*//
amroot = (getuid () == 0);/
...[omitted].../
The setuid/SUID concept is tricky and should be used with utmost caution, otherwise you’ll leave security gaps in your system. It’s an essential security concept and many commands (like the ping command) and programs (like sudo) utilize it.How to set the SUID bit? I find the symbolic way easier while setting the SUID bit. You can use the chmod command in this way:
chmod u+s file_name
The S as SUID flag means there is an error that you should look into. You want the file to be executed with the same permission as the owner but there is no executable permission on the file. Which means that not even the owner is allowed to execute the file and if file cannot be executed, you won’t get the permission as the owner. This fails the entire point of setting the SUID bit.
How to find all files with SUID set?
If you want to search files with this permission, use find command in the terminal with option -perm.
find / -perm /4000
What is SGID?
SGID is similar to SUID. With the SGID bit set, any user executing the file will have same permissions as the group owner of the file. It’s benefit is in handling the directory. When SGID permission is applied to a directory, all sub directories and files created inside this directory will get the same group ownership as main directory (not the group ownership of the user that created the files and directories).
How to set SGID?
You can set the SGID bit in symbolic mode like this:
chmod g+s directory_name
How to find files with SGID set in Linux
To find all the files with SGID bit set, use this command:
find . -perm /2000
How To Get NTFS File Permissions Using PowerShell
iCacls is a built-in command line tool in Windows for reporting NTFS access permissions. It has many options, but PowerShell offers more flexibility in formatting the results.With PowerShell, you can use the Get-Acl cmdlet to get access permissions. The objects generated by Get-Acl can be easily processed by other PowerShell cmdlets, or the output can be formatted for other applications.This article will focus on using Get-Acl with files and folders, but it can also be used with registry keys and other objects.
iCacls is a Windows command-line tool that IT administrators use to change access control lists (ACLs) on files and folders. It’s a very efficient way to modify permissions on a file server.
How to Use the iCacls Command
Many IT professionals usually modify file permissions using File Explorer. They open File Explorer, navigate to the problematic network location, and change user permissions, like from 'Read' to 'Read/Modify'. This method is quick and easy for smaller tasks. However, for large-scale tasks, such as changing permissions on millions of files and folders, the graphical user interface (GUI) in File Explorer isn’t sufficient. For these scenarios, the iCacls command is more suitable and efficient.
What is an Access Control List (ACL)?
In Windows and NTFS filesystems, each file or folder has an access control list (ACL). An ACL contains access control entries (ACEs), which specify the users and groups that have permissions to access the file or folder. This list defines what actions each user or group can perform on the file or folder.What is an Access Control Entry (ACE)?
An access control entry (ACE) is a specific rule in an access control list (ACL) that determines the permissions a user or group has for a file or folder. Here are the main basic permissions available in an ACL:
1. Full access (F)
2. Modify access (M) (includes 'delete')
3. Read and execute access (RX)
4. Read-only access (R)
5. Write-only access (W)
There are also more advanced permissions, but those are outside the scope of this discussion.
Limitations of File Explorer
Imagine you’re managing a file server migration from Server A to Server B. After copying data to Server B, you find that not all permissions are correct. Using File Explorer, you navigate to the root directory, access the Security tab, and make adjustments to the access control list. You opt to apply changes recursively to all 22 million files and folders under the root. The process starts making changes but interrupts you with confirmation prompts for system files, read-only files, and others.Here’s a request: A helpful feature would be a wizard in File Explorer where you could set it to automatically assume 'Yes' for all confirmation prompts. The process would then proceed, handle any errors, and provide a summary with an option to download a raw output file for reviewing any issues that arose. While such a robust feature doesn’t currently exist, IT professionals often turn to command-line tools like iCacls for more comprehensive control over permissions management.
References:
