Access permissions to the file linux

Unix / Linux — File Permission / Access Modes

In this chapter, we will discuss in detail about file permission and access modes in Unix. File ownership is an important component of Unix that provides a secure method for storing files. Every file in Unix has the following attributes −

Owner permissions − The owner’s permissions determine what actions the owner of the file can perform on the file.

Group permissions − The group’s permissions determine what actions a user, who is a member of the group that a file belongs to, can perform on the file.

Other (world) permissions − The permissions for others indicate what action all other users can perform on the file.

The Permission Indicators

While using ls -l command, it displays various information related to file permission as follows −

Here, the first column represents different access modes, i.e., the permission associated with a file or a directory.

The permissions are broken into groups of threes, and each position in the group denotes a specific permission, in this order: read (r), write (w), execute (x) −

The first three characters (2-4) represent the permissions for the file’s owner. For example, -rwxr-xr— represents that the owner has read (r), write (w) and execute (x) permission.

The second group of three characters (5-7) consists of the permissions for the group to which the file belongs. For example, -rwxr-xr— represents that the group has read (r) and execute (x) permission, but no write permission.

The last group of three characters (8-10) represents the permissions for everyone else. For example, -rwxr-xr— represents that there is read (r) only permission.

File Access Modes

The permissions of a file are the first line of defense in the security of a Unix system. The basic building blocks of Unix permissions are the read, write, and execute permissions, which have been described below −

Grants the capability to read, i.e., view the contents of the file.

Write

Grants the capability to modify, or remove the content of the file.

Execute

User with execute permissions can run a file as a program.

Directory Access Modes

Directory access modes are listed and organized in the same manner as any other file. There are a few differences that need to be mentioned −

Access to a directory means that the user can read the contents. The user can look at the filenames inside the directory.

Write

Access means that the user can add or delete files from the directory.

Execute

Executing a directory doesn’t really make sense, so think of this as a traverse permission.

A user must have execute access to the bin directory in order to execute the ls or the cd command.

Changing Permissions

To change the file or the directory permissions, you use the chmod (change mode) command. There are two ways to use chmod — the symbolic mode and the absolute mode.

Using chmod in Symbolic Mode

The easiest way for a beginner to modify file or directory permissions is to use the symbolic mode. With symbolic permissions you can add, delete, or specify the permission set you want by using the operators in the following table.

Adds the designated permission(s) to a file or directory.

Removes the designated permission(s) from a file or directory.

Sets the designated permission(s).

Here’s an example using testfile. Running ls -1 on the testfile shows that the file’s permissions are as follows −

Then each example chmod command from the preceding table is run on the testfile, followed by ls –l, so you can see the permission changes −

Here’s how you can combine these commands on a single line −

Using chmod with Absolute Permissions

The second way to modify permissions with the chmod command is to use a number to specify each set of permissions for the file.

Each permission is assigned a value, as the following table shows, and the total of each set of permissions provides a number for that set.

Sr.No.	Chmod operator & Description
1

Number	Octal Permission Representation	Ref
0	No permission	—
1	Execute permission	—x
2	Write permission	-w-
3	Execute and write permission: 1 (execute) + 2 (write) = 3	-wx
4	Read permission	r—
5	Read and execute permission: 4 (read) + 1 (execute) = 5	r-x
6	Read and write permission: 4 (read) + 2 (write) = 6	rw-
7	All permissions: 4 (read) + 2 (write) + 1 (execute) = 7	rwx

Here’s an example using the testfile. Running ls -1 on the testfile shows that the file’s permissions are as follows −

Then each example chmod command from the preceding table is run on the testfile, followed by ls –l, so you can see the permission changes −

Changing Owners and Groups

While creating an account on Unix, it assigns a owner ID and a group ID to each user. All the permissions mentioned above are also assigned based on the Owner and the Groups.

Two commands are available to change the owner and the group of files −

chown − The chown command stands for «change owner» and is used to change the owner of a file.

chgrp − The chgrp command stands for «change group» and is used to change the group of a file.

Changing Ownership

The chown command changes the ownership of a file. The basic syntax is as follows −

The value of the user can be either the name of a user on the system or the user id (uid) of a user on the system.

The following example will help you understand the concept −

Changes the owner of the given file to the user amrood.

NOTE − The super user, root, has the unrestricted capability to change the ownership of any file but normal users can change the ownership of only those files that they own.

Changing Group Ownership

The chgrp command changes the group ownership of a file. The basic syntax is as follows −

The value of group can be the name of a group on the system or the group ID (GID) of a group on the system.

Following example helps you understand the concept −

Changes the group of the given file to special group.

SUID and SGID File Permission

Often when a command is executed, it will have to be executed with special privileges in order to accomplish its task.

As an example, when you change your password with the passwd command, your new password is stored in the file /etc/shadow.

As a regular user, you do not have read or write access to this file for security reasons, but when you change your password, you need to have the write permission to this file. This means that the passwd program has to give you additional permissions so that you can write to the file /etc/shadow.

Additional permissions are given to programs via a mechanism known as the Set User ID (SUID) and Set Group ID (SGID) bits.

When you execute a program that has the SUID bit enabled, you inherit the permissions of that program’s owner. Programs that do not have the SUID bit set are run with the permissions of the user who started the program.

This is the case with SGID as well. Normally, programs execute with your group permissions, but instead your group will be changed just for this program to the group owner of the program.

The SUID and SGID bits will appear as the letter «s» if the permission is available. The SUID «s» bit will be located in the permission bits where the owners’ execute permission normally resides.

For example, the command −

Shows that the SUID bit is set and that the command is owned by the root. A capital letter S in the execute position instead of a lowercase s indicates that the execute bit is not set.

If the sticky bit is enabled on the directory, files can only be removed if you are one of the following users −

• The owner of the sticky directory
• The owner of the file being removed
• The super user, root

To set the SUID and SGID bits for any directory try the following command −

Источник

Linux file access permissions reference

Introduction

Linux file access permissions are used to control who is able to read, write and execute a certain file. This is an important consideration due to the multi-user nature of Linux systems and as a security mechanism to protect the critical system files both from the individual user and from any malicious software or viruses. Access permissions are implemented at a file level with the appropriate permission set based on the file owner, the group owner of the file and world wide access. In Linux, directories are also files and therefore the file permissions apply on a directory level as well, although some permissions are applied differently depending upon whether the file is a regular file or directory.

As devices are also represented as files then the same permissions commands can be applied to access to certain resources or external devices.

The group mechanism provides each user with a default group (also known as a primary group), but then allows the users to be added to additional groups. This allows users to be given the appropriate level of access by creating a group for each department or job function, restricting access to those groups.

The default group for each user is determined by the set-up of the system. This is normally configured to create a group with the same name as the username that only that user is a member of. This is the most secure default as it means that there are no other users with default access. An alternative is to have a default group that all users have when created.

The access permission design allows a good amount of flexibility in what permissions can be applied. For example it is possible to restrict access to the owner; make files publicly viewable but only editable by the owner and also to apply different permissions based on a group (e.g. members of the same department). There also also features that can also be used to give permissions as though another user (suid). If something beyond the standard file permissions is required then access control lists can be used instead (ACLs). The use of ACLs is less commonly used and they are not discussed in detail here.

Different types of users

Usernames vs. userid and group names vs. groupid

For most of this document I will refer to users and groups by their names. This is the most common and user-friendly way of understanding file permissions. It should however be noted that behind the scenes this is stored as numerical userids (uid) or groupids (gid). The translation from uid / gid is handled by the operating system and the reference stored on the disk is the numerical id. This is not normally important on a single system, but it should be considered when transferring files using an archiving tool (eg. tar) or when moving a disk from one system to another. If the usernames / groupnames have a different numerical uid / gid then access may be given where it is not expected, or rejected where it is required.

The translation between username and userid (uid) is stored in the /etc/passwd file, and the translation from groupname to groupid (gid) is in the /etc/group file. The /etc/passwd file also includes the users primary (default) group and the /etc/group file includes all users that are members of each group (although does not list the user where that is their primary group).

The root user (superuser)

There is a special user on each system with unlimited access to the system. This user has username and groupname of root and the numerical uid and gid of 0. This user is required to allow administrative actions that are not granted under the other users and for certain daemons that have full access to the system. This user is defined by the uid — so multiple superusers could be created by creating multiple entries with this uid. This is not recommended as it provides a potential security issue (see sudo below for the recommended method of providing root access to normal users).

Depending upon the setup and whether physically on the computer or access it remotely it may or may not be possible to login directly as root. It is strongly recommended not to login as root unless it is absolutely necessary due to the risk of accidental deleting important information.

su and sudo

When logging on to a Linux computer you will normally have user level privileges. To elevate to root user access the commands su or sudo are used. These can actually be used to switch to any user, but it is most commonly used when root privileges are required. The commands su and sudo are run on the command line, but there is a graphical version called gksudo. When access is required in a graphical application then it will normally be set-up to prompt for the appropriate authentication automatically. Alternatively it is sometimes possible to right click on an application icon and choose «Run as adminstrator» or «Run as root».

su— The su command is normally used where the user knows the password of the user that they wish to run as. By default this will switch to the root user and the command is often (incorrectly) referred to as the superuser command. If a username is entered on the command-line then it will change to that user instead. If you are already running as root (perhaps through su already) then it will not prompt for a password.

The ‘-‘ (hyphen) can be used to also take the user settings as (e.g. search path) as well as privileges.

The command syntax is:

The following screenshot shows a user switching to the superuser. Note that the root password is entered, not the users password.

sudo — The sudo command can be used as an alternative to the su command, and on some systems in used exclusively (e.g. Ubuntu). The sudo command can be much more flexible than su, depending upon how it is configured. For example sudo can be configured to restrict administrator privileges to certain commands and could even be configured so that the user is not required to enter a password when using sudo (careful thought needs to be made as to the security of the application and whether an unattended session could allow someone to gain access permissions). Where sudo requests the user to enter a password this is normally their own password rather than the root password (Ubuntu and some other distributions take this further by not having a root password meaning that root access can only be obtained through sudo).

Once the user has authenticated themselves using sudo it will normally have a period of time where sudo can be run without having to re-enter the password. This is particularly useful when used with another feature of sudo that allows commands to be run directly rather than changing the permission of the shell session. For example the following example is often used on Ubuntu to install a new application:

sudo apt-get install applicationname

If you wish to run a shell session instead then either the shell should be run on the command-line e.g.

or the -s switch used.

In the example below the user is required to authenticate the first time then run sudo, but can then run subsequent commands without having to re-authenticate. The password given is the users own password and not the root password.

Note I have made the text bold and added a blank space to show the same command being run twice. The password was requested when the command was first run, but not on subsequent runs using the sudo command as it will remember recent authentications.

To run a command as a user other than root the -u username switch is used before the command.

The configuration of sudo is contained within the /etc/sudoers file.

The following show some of the sudoers configuration options. Note that the admin or wheel groups are commonly used to restrict who can run sudo but this is a popular convention rather than a rule. It is possible to use any groupname, or sudo can be configured by listing the authorised users in the sudoers file.

A further advantage of sudo is that user access is logged which may be required as a security feature on a server with multiple adminstrators. For security and configuration options sudo is usually preferred over su.

The following extract allows root or members of the admin group to su to any other user.

User permission on files

Having discussed the different types of users and groups these are then applied to files based on the file permissions. This does not just apply to data files, but can be applied to directories to determine who can change to the particular directory and to commands to restrict who can run that command.

File Structure (Inodes)

To understand the way that permissions work it is often useful to understand how the file permissions are stored on the disk. This gets a little technical so if you don’t feel ready for this feel free to skip to the next section on file permissions.

Each file on disk has two parts. The Inode which describes the file and the data blocks that actually hold the data. The file permissions are contained within the Inode for the file.

The following information is kept within the Inode:
Size of file
Permissions
Date & time of creation
Date & time of last modification
Link count

It is the Inode that is referenced by the operating system when determining if a user has the relevant permissions.

Directories exist as links to the Inodes of all the files (or other sub-directories) contained within that directory. This is shown below;

Directory structure on the disk

File Permissions

The file permissions can be seen by using the ls command with the -l (long listing option) as shown below

From the ls output the file permissions can be seen at the left.
These are the first 10 characters of the file entry. The first character relates to the file type then the remaining are in 3 groups of 3 characters relating to the different access types.

These permissions are applied to (left to right)
user — the owner of the file
group — a group of people, e.g. a project team or department
others — anyone else that has a login to the computer

These are then split into 3 different permissions, that of being able to:

These are laid out as follows (note these are the first 10 characters of the ls -l display):

Access permission layout

If the entry is filled in then it is in affect. If it is dashed out ‘-‘ then it does not apply.

There are also further permissions that can be set, however these are more advanced and are explained later. Also note that root can override most of the permissions.

Changing File Permissions (chmod)

Assuming that you are either the owner of the file or root it is possible for you to change the permissions of a file to either add or remove permissions. This is done using the chmod (change mode) command.

The chmod command can be used in one of two ways. The Symbolic Format or the octal format. Symbolic is useful for new users as it is easier to use, however if effort is made to understand the octal format then it can be a powerful and quick way of changing file permissions.

The basic format of the command is:

chmod mode filename

It is only the format of the mode parameter that is different when using the different permission formats.

In symbolic format permissions are added or deleted using the following symbols

For example to add write access to the group the following command is used:

In Octal format the mode is based upon a octal number representing the different mode permissions, where each of the permission groups (user, group, others) has an octal value representing the read, write and execute bits. This requires a little bit of knowledge on binary or octal number bases. The format is actually octal (but this can be likened to 3 separate binary to decimal conversions for each of the user/group/all permissions). The main benefits of using octal format is that all the permissions are set at the same time and the command is much shorter than if all the permissions were set using the symbolic format.

The above file would have the octal number 764 and would therefore be changed using the command

chmod 764 file1

An alternative way of working out the octal values is to add the following numbers depending upon the permission required.
Read = 4
Write = 2
Execute = 1

Therefore if you wanted to set read to yes, write to no and execute to yes, this would be 4+1=5

Setuid, setgid and the sticky bit

So far we have covered the most common file permissions that users will need to be familiar with. There is a further set of permissions that gives more functionality beyond that of the standard permissions. These are the setuid and setgid options, and the sticky bit. These are shown by ls within the normal file permissions by replacing the execute bit is normally shown by replacing it with S, s, T or t as appropriate.

A lower case s is used where the execute bit is on, and an upper case S where the execute bit is not set.
When used on an executable file this will make the command run as the owner of the file (often root) rather than the person that launched the application. This is required where a regular user needs to run a program that needs to access files that can only be read/written to by root. For example the passwd command which needs to access the protected shadow password file:

It can however be a security risk if it is set on a command that either has a way that users can run other commands (as they will also run as root), or if there is a bug in the application.

The setgid bit is similar to the setuid bit, but is set on the group permissions. This means that a command will run as the group that owns the file rather than the user’s default group.

The sticky bit is used to restrict who can delete a file in a directory. When viewing using ls it replaces the world execute permission with a lower case t if the execute bit is set on, and an upper case T if the execute bit is off. When this is set on a directory then only the owner of a file (or root) can delete a file within that directory. This is used in the /tmp directory to allow users to create temporary files, but stop anyone other than that user from deleting the temporary file.

To set any of these special permissions using the octal format then an additional digit is used before the rest of the octal number. This is created the same as another octal value using setuid, setgid, sticky in place of rwx.

For example the octal number 4755, would set the setuid bit (4) and the rest of the permissions as per the passwd command shown previously.

Changing the file owner (chown)

The owner and group owner of a file is normally set to the user and default group of the person that created the file.

The owner or group can be changed using the chown (change owner) command.

The format is as follows:

chown user:group filename

Setting default permissions (umask)

The default permission for new files created depends upon the umask value.

Umask works by restricting what permissions are given to a file when it is created by a new program. If the program tries to give full permissions then the umask will restrict what permissions are actually set. If however the program requests permissions that are less than the umask then umask will not add any additional permissions.

The mask works by applying the negative of the umask setting anded with the permissions requested. In effect performing an AND NOT against the umask value.

This is set in the /etc/profile or /etc/bashrc for all users, but can be changed in the users

The umask should be set as a inverse mask of the permissions required.

For example the umask of 077 will mean that the group and all users have no permission.

Источник