Linux Permissions Basics

The content of this article is based or taken from the Cisco's Networking Academy NDG Linux Essentials, Chapter 17 – Ownership and Permissions and Chapter 18 – Special Directories and Files.

Permissions

The output of the ls ‑l command displays ten characters at the beginning of each line. These characters indicate the type of file and the permissions of the file. For example, consider the output of the following command:

ls -l /etc/passwd

-rw-r--r--. 1 root root 4135 May 27 21:08 /etc/passwd

The stat command displays more detailed information about a file, including providing the group ownership both by group name and GID number:

stat /etc/passwd

  File: /etc/passwd
  Size: 1835            Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 3016073     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-06-04 11:15:14.749541612 +0300
Modify: 2022-03-13 10:11:44.222373720 +0200
Change: 2022-03-13 10:11:44.222373720 +0200
 Birth: 2022-03-13 10:11:44.222373720 +0200

File Type

The first character of each line indicates the type of file:

-rw-r--r-- 1 root root 4135 May 27 21:08 /etc/passwd

The following table describes the possible values for the file type:

Character	Type of the File
`-`	A `regular file`, which may be empty, or contain text or binary data.
`d`	A `directory file`, which contains the names of other files and links to them.
`l`	A `symbolic link` is a file name that refers (points) to another file.
`b`	A `block file` is one that relates to a block hardware device where data is read in blocks of data.
`c`	A `character file` is one that relates to a character hardware device where data is read one byte at a time.
`p`	A `pipe file` works similar to the pipe symbol, allowing for the output of one process to communicate to another process through the pipe file, where the output of the one process is used as input for the other process.
`s`	A `socket file` allows two processes to communicate, where both processes are allowed to either send or receive data.

Consider This: Although all the file types are listed in the table above, typically you don’t encounter anything but regular, directory and link files unless you explore the /dev directory.

Permission Groups

The next nine characters demonstrate the permissions of the file.

-rw-r--r-- 1 root root 4135 May 27 21:08 /etc/passwd

The permissions set on these files determine the level of access that a user has on the file. When a user runs a program and the program accesses a file, then the permissions are checked to determine whether the user has the correct access rights to the file.

The permissions are grouped into three different roles, representing the different users that may try to access the file.

If you aren't the owner and you're not a member of the file/directory group, then your permissions would be others.

User Owner

-rw-r--r-- 1 root root 4135 May 27 21:08 /etc/passwd

Characters 2–4 indicate the permissions for the user that owns the file. If you are the owner of the file, then only the user owner permissions are used to determine access to that file.

Group Owner

-rw-r--r-- 1 root root 4135 May 27 21:08 /etc/passwd

Characters 5–7 indicate the permissions for the group that owns the file. If you are not the owner but are a member of the group that owns the file, then only group owner permissions are used to determine access to that file.

Other Permissions

-rw-r--r-- 1 root root 4135 May 27 21:08 /etc/passwd

Characters 8–10 indicate the permissions for others or what is sometimes referred to as the world's permissions. This group includes all users who are not the file owner or a member of the file's group.

Permission Types

Each group is attributed three basic types of permissions: read, write, and execute.

User Owner

Group Owner

Other

r	w	x
Read	Write	Execute

r	w	x
Read	Write	Execute

r	w	x
Read	Write	Execute

The permissions themselves are deceptively simple and have a different meaning depending on whether they are applied to a file or a directory.

Read

The first character of each group represents the read permission. There is an r character if the group has the read permission, or a - character if the group does not.

On a file, this allows processes to read the contents of the file, meaning the contents can be viewed and copied.
On a directory, file names in the directory can be listed, but other details are not available.

Write

The second character of each group represents the write permission. There is a w character if the group has the write permission, or a - character if the group does not.

A file can be written to by the process, so changes to a file can be saved. Note that w permission really requires r permission on the file to work correctly.
On a directory, files can be added to or removed from the directory. Note that w permission requires x permission on the directory to work correctly.

Execute

The third character of each group represents the execute permission. There is an x character if the group has the execute permission, or a - character if the group does not.

A file can be executed or run as a process.
On a directory, the user can use the cd command to "get into" the directory and use the directory in a pathname to access files and, potentially, subdirectories under this.

Symbolic Method

If you want to modify some of the current permissions, the symbolic method is usually easier to use. With this method, you specify which permissions you want to change on the file, and the other permissions remain as they are.

When specifying the new_permission argument of the chmod command using the symbolic method three types of information are required.

Start by using one or more of the following characters to indicate which permission group(s) to apply the changes to:

`u`	user owner
`g`	group owner
`o`	others
`a`	all (user owner, group owner, and others)

‌⁠⁠Then choose one of the following operators to indicate how to modify the permissions:

`+`	add
`-`	remove
`=`	equals

Lastly, use the following characters to specify the permissions type(s) to change:

`r`	read
`w`	write
x	execute

For example, to give the group owner write permission on a file named abc.txt, you could use the following command:

chmod g+w abc.txt
ls -l abc.txt

-rw-rw-r-- 1 root root 0 Dec 19 18:58 abc.txt

Only the group owner's permission was changed. All other permissions remained as they were prior to the execution of the chmod command.

You can combine values to make multiple changes to the file's permissions. For example, consider the following command which adds the execute permission to the user owner and group owner and removes the read permission for others:

chmod ug+x,o-r abc.txt
ls -l abc.txt

-rwxrwx--- 1 root root 0 Dec 19 18:58 abc.txt

Lastly, you could use the = character, which adds specified permissions and causes unmentioned ones to be removed. For example, to give the user owner only read and execute permissions, removing the write permission:

chmod u=rx abc.txt
ls -l abc.txt

-r-xrwx--- 1 root root 0 Dec 19 18:58 abc.txt

More examples:

`chmod a+x file`	Gives everyone execute permission
`chmod g‑w file`	Removes write permission for group owners
`chmod go+r file`	Adds read permission for group owner and others
`chmod o=rwx`	Sets others permissions to read, write and execute

Numeric Method

The numeric method (also called the octal method) is useful when changing many permissions on a file. It is based on the octal numbering system in which each permission type is assigned a numeric value:

4	Read
2	Write
1	Execute

By using a combination of numbers from 0 to 7, any possible combination of read, write and execute permissions can be specified for a single permission group set. For example:

7	`rwx`
6	`rw-`
5	`r‑x`
4	`r–`
3	`-wx`
2	`-w-`
1	`–x`
0	`—`

The new_permission argument is specified as three numbers, one number for each permission group. When the numeric method is used to change permissions, all nine permissions must be specified. Because of this, the symbolic method is generally easier for changing a few permissions while the numeric method is better for changes that are more drastic.

For example, to set the permissions of a file named abc.txt to be rwxr-xr– you could use the following command:

chmod 754 abc.txt
ls -l abc.txt

-rwxr-xr-- 1 root root 0 Dec 19 18:58 abc.txt

To use the chmod command with octal notation, you must first understand the octal value of the permissions:

Read `r`	4
Write `w`	2
Execute `x`	1

From the last listing of the abc.txt file, the permissions were shown to be rwx for the user owner, r‑x for the group owner, and r– for others. To express these permissions in octal notation, a total is calculated for each ownership.

As a result, the user's permission total would be calculated as 4 + 2 + 1, or 7, where 4 is for the read, 2 is for the write, and 1 is for the execute permission.

The group's permission total would be 4 + 1 or 5, where 4 is for the read permission, and 1 is for the execute permission.

The others' ownership permission would simply be 4 for the read permission that they have.

Putting it all together, the octal value for the current permissions would be 754.

Default Permissions

The umask command is a feature that is used to determine default permissions that are set when a file or directory is created. Default permissions are determined when the umask value is subtracted from the maximum allowable default permissions. The maximum default permissions are different for files and directories:

file	`rw-rw-rw-`
directories	`rwxrwxrwx`

The permissions that are initially set on a file when it is created cannot exceed rw-rw-rw-. To have the execute permission set on a file, you first need to create the file and then change the permissions.

The umask command can be used to display the current umask value:

umask

A breakdown of the output:

The first 0 indicates that the umask is given as an octal number.
The second 0 indicates which permissions to subtract from the default user owner's permissions.
The third 0 indicates which permissions to subtract from the default group owner's permissions.
The last number 2 indicates which permissions to subtract from the default other's permissions.

Note that different users may have different umasks. Typically the root user has a more restrictive umask than normal user accounts:

umask

To understand how umask works, assume that the umask of a file is set to 027 and consider the following:

File Default	`666`
Umask	`-027`
Result	`640`

The 027 umask means that new files would receive 640 or rw‑r—– permissions by default, as demonstrated below:

umask 027
touch sample 
ls -l sample

-rw-r-----. 1 sysadmin sysadmin 0 Oct 28 20:14 sample

Because the default permissions for directories are different than for files, a umask of 027 would result in different initial permissions on new directories:

Directory Default	`777`
Umask	`-027`
Result	`750`

The 027 umask means that directories files would receive 750 or rwxr‑x— permissions by default, as demonstrated below:

umask 027
mkdir test-dir
ls -ld test-dir

drwxr-x---. 1 sysadmin sysadmin 4096 Oct 28 20:25 test-dir

The new umask is only applied to file and directories created during that session. When a new shell is started, the default umask will again be in effect.

Permanently changing a user's umask requires modifying the .bashrc file located in that user's home directory.

Setuid

When the setuid permission is set on an executable binary file (a program) the binary file is run as the owner of the file, not as the user who executed it. This permission is set on a handful of system utilities so that they can be run by normal users, but executed with the permissions of root, providing access to system files that the normal user doesn't normally have access to.

Consider the following scenario in which the user sysadmin attempts to view the contents of the /etc/shadow file:

more /etc/shadow

/etc/shadow: Permission denied

ls -l /etc/shadow

-rw-r-----. 1 root root 5195 Oct 21 19:57 /etc/shadow

The permissions on /etc/shadow do not allow normal users to view (or modify) the file. Since the file is owned by the root user, the administrator can temporarily modify the permissions to view or modify this file.

Now consider the passwd command. When this command runs, it modifies the /etc/shadow file, which seems impossible because other commands that the sysadmin user runs that try to access this file fail. So, why can the sysadmin user modify the /etc/shadow file while running the passwd command when normally this user has no access to the file?

The passwd command has the special setuid permission set. When the passwd command is run, and the command accesses the /etc/shadow file, the system acts as if the user accessing the file is the owner of the passwd command (the root user), not the user who is running the command.

You can see this permission set by running the ls ‑l command:

ls -l /usr/bin/passwd

-rwsr-xr-x 1 root root 31768 Jan 28 2010 /usr/bin/passwd

Notice the output of the ls command above; the setuid permission is represented by the s in the owner permissions where the execute permission would normally be represented. A lowercase s means that both the setuid and execute permission are set, while an uppercase S means that only setuid and not the user execute permission is set.

Like the read, write and execute permissions, special permissions can be set with the chmod command, using either the symbolic and octal methods.

To add the setuid permission symbolically, run:

chmod u+s file

To add the setuid permission numerically, add 4000 to the file's existing permissions (assume the file originally had 775 for its permission in the following example):

chmod 4775 file

To remove the setuid permission symbolically, run:

chmod u-s file

To remove the setuid permission numerically, subtract 4000 from the file's existing permissions:

chmod 0775 file

Previously, we set permission with the octal method using three-digit codes. When a three-digit code is provided, the chmod command assumes that the first digit before the three-digit code is 0. Only when four digits are specified is a special permission set.

If three digits are specified when changing the permission on a file that already has a special permission set, the first digit will be set to 0, and the special permission will be removed from the file.

Setgid

The setgid permission is similar to setuid, but it makes use of the group owner permissions. There are two forms of setgid permissions: setgid on a file and setgid on a directory. The behavior of setgid depends on whether it is set on a file or directory.

Setgid on Files

The setgid permission on a file is very similar to setuid; it allows a user to run an executable binary file in a manner that provides them additional (temporary) group access. The system allows the user running the command to effectively belong to the group that owns the file, but only in the setgid program.

A good example of the setgid permission on an executable file is the /usr/bin/wall command. Notice the permissions for this file as well as the group owner:

ls -l /usr/bin/wall

-rwxr-sr-x 1 root tty 30800 May 16 2018 /usr/bin/wall

You can see that this file is setgid by the presence of the s in the group's execute position. Due to this executable being owned by the tty group, when a user executes this command, the command is able to access files that are group owned by the tty group.

This access is important because the /usr/bin/wall command sends messages to terminals, which is accomplished by writing data to files like the following:

ls -l /dev/tty?

crw--w----. 1 root tty 4, 0 Mar 29  2013 /dev/tty0 
crw--w----. 1 root tty 4, 1 Oct 21 19:57 /dev/tty1

Note that the tty group has write permission on the files above while users who are not in the tty group ("others") have no permissions on these files. Without the setgid permission, the /usr/bin/wall command would fail.

Setgid on Directories

When set on a directory, the setgid permission causes files created in the directory to be owned by the group that owns the directory automatically. This behavior is contrary to how new file group ownership would normally function, as by default new files are group owned by the primary group of the user who created the file.

In addition, any directories created within a directory with the setgid permission set are not only owned by the group that owns the setgid directory, but the new directory automatically has setgid set on it as well. In other words, if a directory is setgid, then any directories created within that directory inherit the setgid permission.

By default when the ls command is executed on a directory, it outputs information on the files contained within the directory. To view information about the directory itself add the -d option. Used with the -l option, it can be used to determine if the setgid permission is set. The following example shows that the /tmp/data directory has the setgid permission set and that it is owned by the demo group.

ls -ld /tmp/data

drwxrwsrwx. 2 root demo 4096 Oct 30 23:20 /tmp/data

In a long listing, the setgid permission is represented by an s in the group execute position. A lowercase s means that both setgid and group execute permissions are set:

drwxrwsrwx. 2 root demo 4096 Oct 30 23:20 /tmp/data

An uppercase S means that only setgid and not group execute permission is set. If you see an uppercase S in the group execute position of the permissions, then it indicates that although the setgid permission is set, it is not really in effect because the group lacks the execute permission to use it:

drwxrwSr-x. 2 root root 5036 Oct 30 23:22 /tmp/data2

Typically files created by the user sysadmin are owned by their primary group, also called sysadmin.

id

uid=500(sysadmin) gid=500(sysadmin) 
groups=500(sysadmin),10001(research),10002(development) 
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

However, if the user sysadmin creates a file in the /tmp/data directory, the setgid directory from the preceding example, the group ownership of the file isn't the sysadmin group, but rather the group that owns the directory demo:

touch /tmp/data/file.txt 
ls -ld /tmp/data/file.txt

-rw-rw-r--. 1 bob demo 0 Oct 30 23:21 /tmp/data/file.txt

Why would an administrator want to set up a setgid directory? First, consider the following user accounts:

The user bob is a member of the payroll group.
The user sue is a member of the staff group.
The user tim is a member of the acct group.

In this scenario, these three users need to work on a joint project. They approach the administrator to ask for a shared directory in which they can work together, but that no one else can access their files. The administrator does the following:

Creates a new group called team.
Adds bob, sue, and tim to the team group.
Makes a new directory called /home/team.
Makes the group owner of the /home/team directory be the team group.
Gives the /home/team directory the following permissions: rwxrwx—

As a result, bob, sue, and tim can access the /home/team directory and add files. However, there is a potential problem: when bob creates a file in the /home/team directory, the new file is owned by his primary group:

-rw-r-----. 1 bob payroll 100 Oct 30 23:21 /home/team/file.txt

Unfortunately, while sue and tim can access the /home/team directory, they can't do anything with bob's file. Their permissions for that file are the others permissions (—).

If the administrator sets the setgid permission to the /home/team directory, then when bob creates a file, it is owned the team group:

-rw-r-----. 1 bob team 100 Oct 30 23:21 /home/team/file.txt

As a result, sue and tim would have access to the file through the group owner permissions (r–).

Certainly, bob could change the group ownership or the others permissions after creating the file, but that would become tedious if there were many new files being created. The setgid permission makes it easier for this situation.

Setting Setgid

Use the following syntax to add the setgid permission symbolically:

chmod g+s <file|directory>

To add the setgid permission numerically, add 2000 to the file's existing permissions (assume in the following example that the directory originally had 775 for its permissions):

chmod 2775 <file|directory>

To remove the setgid permission symbolically, run:

chmod g-s <file|directory>

To remove the setgid permission numerically, subtract 2000 from the file's existing permissions:

chmod 0775 <file|directory>

Sticky Bit

The sticky bit permission is used to prevent other users from deleting files that they do not own in a shared directory. Recall that any user with write permission on a directory can create files in that directory, as well as delete any file in the directory, even if they do not own the file!

The sticky bit permission allows for files to be shared with other users, by changing write permission on the directory so that users can still add and delete files in the directory, but files can only be deleted by the owner of the file or the root user.

A good example of the use of sticky bit directories would be the /tmp and /var/tmp directories. These directories are designed as locations where any user can create a temporary file.

Because these directories are intended to be writable by all users, they are configured to use the sticky bit. Without this special permission, users would be able to delete any files in this directory, including those that belong to other users.

The output of the ls ‑l command displays the sticky bit by a t character in the execute bit of the others permission group:

ls -ld /tmp

drwxrwxrwt 1 root root 4096 Mar 14 2016 /tmp

A lowercase t means that both the sticky bit and execute permissions are set for others. An uppercase T means that only the sticky bit permission is set.

While the capital S indicated a problem with the setuid or setgid permissions, a capital T does not necessarily indicate a problem, as long as the group owner still has the execute permission.

To set the sticky bit permission symbolically, execute a command like the following:

chmod o+t <directory>

To set the sticky bit permission numerically, add 1000 to the directory's existing permissions (assume the directory in the following example originally had 775 for its permissions):

chmod 1775 <file|directory>

To remove the sticky permission symbolically, run:

chmod o-t <directory>

‌⁠⁠To remove the sticky bit permission numerically, subtract 1000 from the directory's existing permissions:

chmod 0775 <directory>

Links

Each linking method, hard and symbolic (soft), results in the same overall access, but uses different techniques. There are pros and cons to each method, so knowing both techniques and when to use them is important.

Hard Links

To understand hard links, it is helpful to understand a little bit about how the file system keeps track of files. For every file created, there is a block of data on the file system that stores the metadata of the file. Metadata includes information about the file like the permissions, ownership, and timestamps. Metadata does not include the file name or the contents of the file, but it does include just about all other information about the file.

This metadata is called the file's inode table. The inode table also includes pointers to the other blocks on the file system called data blocks where the data is stored.

Every file on a partition has a unique identification number called an inode number. The ls ‑i command displays the inode number of a file.

ls -i /tmp/file.txt

215220874 /tmp/file.txt

Like users and groups, what defines a file is not its name, but rather the number it has been assigned. The inode table does not include the file name. For each file, there is also an entry that is stored in a directory's data area (data block) that includes an association between an inode number and a file name.

Like users and groups, what defines a file is not its name, but rather the number it has been assigned. The inode table does not include the file name. For each file, there is also an entry that is stored in a directory's data area (data block) that includes an association between an inode number and a file name.

In the data block for the /etc directory, there would be a list of all of the files in this directory and their corresponding inode number. For example:

File Name	Inode Number
`passwd`	123
`shadow`	175
`group`	144
`gshadow`	897

When you attempt to access the /etc/passwd file, the system uses this table to translate the file name into an inode number. It then retrieves the file data by looking at the information in the inode table for the file.

Hard links are two file names that point to the same inode. For example, consider the following directory entries:

File Name	Inode Number
`passwd`	123
`mypasswd`	123
`shadow`	175
`group`	144
`gshadow`	897

Because both the passwd and mypasswd file have the same inode number, they essentially are the same file. You can access the file data using either file name.

When you execute the ls ‑li command, the number that appears for each file between the permissions and the user owner is the link count number:

echo data > file.original
ls -li file.*

278772 -rw-rw-r--. 1 sysadmin sysadmin 5 Oct 25 15:42 file.original

The link count number indicates how many hard links have been created. When the number is a value of one, then the file has only one name linked to the inode. To create hard links, the ln command is used with two arguments. The first argument is an existing file name to link to, called a target, and the second argument is the new file name to link to the target.

ln <target> <link_name>

When the ln command is used to create a hard link, the link count number increases by one for each additional filename:

ln file.original file.hard.1
ls -li file.*

278772 -rw-rw-r--. 2 sysadmin sysadmin 5 Oct 25 15:53 file.hard.1 
278772 -rw-rw-r--. 2 sysadmin sysadmin 5 Oct 25 15:53 file.original

Important: You cannot create hard links to directories. Also, a hard link to a file must exist within the same filesystem (partition) as the file that it links to.

Symbolic Links

A symbolic link, also called a soft link, is simply a file that points to another file. There are several symbolic links already on the system, including several in the /etc directory:

ls -l /etc/grub.conf

lrwxrwxrwx. 1 root root 22 Feb 15 2011 /etc/grub.conf -> ../boot/grub/grub.conf

In the previous example, the file /etc/grub.conf "points to" the ../boot/grub/grub.conf file. So, if you were to attempt to view the contents of the /etc/grub.conf file, it would follow the pointer and show you the contents of the ../boot/grub/grub.conf file. To create a symbolic link, use the -s option with the ln command:

ln -s <target> <link_name>

ln -s /etc/passwd mypasswd
ls -l mypasswd

lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 mypasswd -> /etc/passwd

Consider This: Notice that the first bit of the ls ‑l output is the l character, indicating that the file type is a link.

Comparing Hard and Symbolic Links

While hard and symbolic links have the same result, the different techniques produce different advantages and disadvantages. In fact, the advantage of one technique compensates for a disadvantage of the other technique.

Advantage: Hard links don’t have a single point of failure.

One of the benefits of using hard links is that every file name for the file content is equivalent. If you have five files hard linked together, then deleting any four of these files would not result in deleting the actual file contents.

Recall that a file is associated with a unique inode number. As long as one of the hard linked files remains, then that inode number still exists, and the file data still exists.

Symbolic links, however, have a single point of failure: the original file. Consider the following example in which access to the data fails if the original file is deleted. The mytest.txt file is a symbolic link to the text.txt file:

ls -l mytest.txt

lrwxrwxrwx. 1 sysadmin sysadmin 8 Oct 31 13:29 mytest.txt -> test.txt

more test.txt

hi there

more mytest.txt

hi there

If the original file, the test.txt file is removed, then any files linked to it, including the mytest.txt file, fail:

rm test.txt
more mytest.txt

mytest.txt: No such file or directory

ls -l mytest.txt

lrwxrwxrwx. 1 sysadmin sysadmin 8 Oct 31 13:29 mytest.txt -> test.txt

Advantage: Soft links are easier to see.

Sometimes it can be difficult to know where the hard links to a file exist. If you see a regular file with a link count that is greater than one, you can use the find command with the -inum search criteria to locate the other files that have the same inode number. To find the inode number you would first use the ls ‑i command:

ls -i file.original

278772 file.original

find / -inum 278772 2> /dev/null

/home/sysadmin/file.hard.1 
/home/sysadmin/file.original

Soft links are much more visual, not requiring any extra commands beyond the ls command to determine the link:

ls -l mypasswd

lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 mypasswd -> /etc/passwd

Advantage: Soft links can link to any file.

Since each file system (partition) has a separate set of inodes, hard links cannot be created that attempt to cross file systems:

ln /boot/vmlinuz-2.6.32-358.6.1.el6.i686 Linux.Kernel

ln: creating hard link `Linux.Kernel' => `/boot/vmlinuz-2.6.32-358.6.1.el6.i686': Invalid cross-device link

In the previous example, a hard link was attempted to be created between a file in the /boot file system and the / file system; it failed because each of these file systems has a unique set of inode numbers that can't be used outside of the filesystem.

However, because a symbolic link points to another file using a pathname, you can create a soft link to a file in another filesystem:

ln -s /boot/vmlinuz-2.6.32-358.6.1.el6.i686 Linux.Kernel
ls -l Linux.Kernel

lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 Linux.Kernel -> /boot/vmlinuz-2.6.32-358.6.1.el6.i686

Advantage: Soft links can link to a directory.

Another limitation of hard links is that they cannot be created on directories. The reason for this limitation is that the operating system itself uses hard links to define the hierarchy of the directory structure. The following example shows the error message that is displayed if you attempt to hard link to a directory:

ln /bin binary

ln: `/bin': hard link not allowed for directory

Linking to directories using a symbolic link is permitted:

ln -s /bin binary
ls -l binary

lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 binary -> /bin

References

Red Hat Docs: An introduction to Linux Access Control Lists (ACLs)
Java T Point: Advanced File Permission
Geeks for Geeks: Advance File Permissions in Linux

Anonymous

Search

Linux Permissions Basics

Namespaces

More

Page actions

Contents

Permissions

File Type

Permission Groups

Permission Types

Symbolic Method

Numeric Method

Default Permissions

Setuid

Setgid

Setgid on Files

Setgid on Directories

Setting Setgid

Sticky Bit

Links

Hard Links

Symbolic Links

Comparing Hard and Symbolic Links

References

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

Linux Permissions Basics

Per­mis­sions

File Type

Per­mis­sion Groups

Per­mis­sion Types

Sym­bol­ic Method

Nu­mer­ic Method

De­fault Per­mis­sions

Se­tu­id

Set­gid

Set­gid on Files

Set­gid on Di­rec­to­ries

Set­ting Set­gid

Sticky Bit

Links

Hard Links

Sym­bol­ic Links

Com­par­ing Hard and Sym­bol­ic Links

Ref­er­ences

Navigation

Wiki tools

Page tools

Categories

Permissions

Permission Groups

Permission Types

Symbolic Method

Numeric Method

Default Permissions

Setuid

Setgid

Setgid on Files

Setgid on Directories

Setting Setgid

Symbolic Links

Comparing Hard and Symbolic Links

References