Access Control Lists (Русский)

Списки управления доступом (Access Control Lists, ACL) — расширенный, более гибкий механизм прав доступа для файловых систем, разработанный как дополнение к стандартным правам доступа UNIX. ACL позволяет задавать права доступа к объектам на диске для пользователей и групп.

Contents

Установка

Пакет acl уже установлен, так как является зависимостью systemd.

Включение ACL

Для использования ACL файловая система должна быть смонтирована с опцией acl . Файл fstab позволяет настроить постоянное монтирование с данной опцией.

В некоторых файловых системах параметр монтирования acl включён по умолчанию. К таким файловым системам относятся Btrfs и Ext2/3/4. Следующая команда позволяет проверить раздел с файловой системой ext* на наличие параметра acl :

Убедитесь, что используемая по умолчанию опция не была переопределена. Об этом будет свидетельствовать параметр noacl в соответствующей строке файла /proc/mounts .

Задать параметры монтирования файловой системы по умолчанию можно командой tune2fs -o параметр раздел , например:

Это очень удобно при работе с внешними дисками, поскольку такой диск будет монтироваться с опцией acl и на других Linux-машинах. В противном случае придётся редактировать файл /etc/fstab на каждой системе.

Использование

Изменение ACL

Для изменения прав ACL используется команда setfacl.

Задать права пользователя (в качестве пользователь можно использовать имя пользователя или его ID):

Задать права группы (в качестве группа можно использовать имя группы или её ID):

Задать права для остальных:

Настроить наследование новыми файлами и каталогами записей ACL родительского каталога (не относится к файлам/каталогам, которые копируются в каталог):

Удалить определённую запись ACL:

Удалить записи по умолчанию:

Удалить все записи ACL:

The factual accuracy of this article or section is disputed.

Просмотр ACL

Вывести права доступа ACL:

Примеры

Установить все права доступа к файлу abc для пользователя johnny :

Измененить права для пользователя johnny :

Удалить все записи ACL:

Вывод команды ls

Символ + (плюс) после прав доступа Unix в выводе команды ls -l указывает на использование ACL:

Права на выполнение личных файлов

Ниже описано, как процесс вроде веб-сервера может получить доступ к файлам в домашнем каталоге пользователя без ущерба для безопасности.

Будем считать что веб-сервер работает от пользователя http и получает доступ к домашнему каталогу /home/geoffrey пользователя geoffrey .

Санчала предоставим права на выполнение для пользователя http :

Поскольку пользователь http теперь имеет доступ к файлам в /home/geoffrey то безопаснее будет удалить доступ для остальных пользователей:

Проверим изменения с помощью getfacl :

Как видно из вывода, other больше не имеют никаких прав, но пользователь http всё ещё может обращаться к файлам.

Если необходимо будет выдать пользователю http права доступа на запись в определённые файлы/каталоги, выполните:

Источник

Access Control Lists

Access control list (ACL) provides an additional, more flexible permission mechanism for file systems. It is designed to assist with UNIX file permissions. ACL allows you to give permissions for any user or group to any disk resource.

Contents

Installation

The acl package is a dependency of systemd, it should already be installed.

Enable ACL

To enable ACL, the filesystem must be mounted with the acl option. You can use fstab to make it permanent on your system.

There is a possibility that the acl option is already active as default mount option on the filesystem. Btrfs does and Ext2/3/4 filesystems do too. Use the following command to check ext* formatted partitions for the option:

Also check that the default mount option is not overridden, in such case you will see noacl in /proc/mounts in the relevant line.

You can set the default mount options of a filesystem using the tune2fs -o option partition command, for example:

Using the default mount options instead of an entry in /etc/fstab is very useful for external drives, such partition will be mounted with acl option also on other Linux machines. There is no need to edit /etc/fstab on every machine.

Usage

Set ACL

The ACL can be modified using the setfacl command.

To set permissions for a user ( user is either the user name or ID):

To set permissions for a group ( group is either the group name or ID):

To set permissions for others:

To allow all newly created files or directories to inherit entries from the parent directory (this will not affect files which will be copied into the directory):

To remove a specific entry:

To remove the default entries:

To remove all entries (entries of the owner, group and others are retained):

The factual accuracy of this article or section is disputed.

Show ACL

To show permissions, use:

Examples

Set all permissions for user johnny to file named abc :

Change permissions for user johnny :

Remove all ACL entries:

Output of ls command

You will notice that there is an ACL for a given file because it will exhibit a + (plus sign) after its Unix permissions in the output of ls -l .

Execution permissions for private files

The following technique describes how a process like a web server can be granted access to files that reside in a user’s home directory, without compromising security by giving the whole world access.

In the following we assume that the web server runs as the user http and grant it access to geoffrey ‘s home directory /home/geoffrey .

The first step is granting execution permissions for the user http :

Since the user http is now able to access files in /home/geoffrey , others no longer need access:

Use getfacl to verify the changes:

As the above output shows, other ‘s no longer have any permissions, but the user http is still able to access the files, thus security might be considered increased.

If you need to give write access for the user http on specific directories and/or files, run:

Источник

Access Control Lists in Linux

This chapter provides a brief summary of the background and functions of POSIX ACLs for Linux file systems. Learn how the traditional permission concept for file system objects can be expanded with the help of ACLs ( Access Control Lists ) and which advantages this concept provides.

Advantages of ACLs

Note

[POSIX ACLs]The term «POSIX ACL» suggests that this is a true POSIX ( Portable Operating System Interface ) standard. The respective draft standards POSIX 1003.1e and POSIX 1003.2c have been withdrawn for several reasons. Nevertheless, ACLs as found on many systems belonging to the UNIX family are based on these documents and the implementation of file system ACLs as described in this chapter follows these two standards as well. They can be viewed at http://wt.xpilot.org/publications/posix.1e/

Traditionally, a file object in Linux is associated with three sets of permissions. These sets includes the read ( r ), write ( w ), and execute ( x ) permissions for each on of three types of users — the file owner, the group, and other users. In addition to that, it is possible to set the set user id , set group id , and the sticky bit. A more detailed discussion of this topic can be found in the section Users and Access Permissions of the User Guide .

This lean concept is fully adequate for most practical cases. However, for more complex scenarios or advanced applications, system administrators formerly had to use a number of tricks to circumvent the limitations of the traditional permission concept.

ACLs can be used for situations that require an extension of the traditional file permission concept. They allow assignment of permissions to individual users or groups even if these do not correspond to the original owner or the owning group. Access Control Lists are a feature of the Linux kernel and are currently supported by ReiserFS, Ext2, Ext3, JFS, and XFS. Using ACLs, complex scenarios can be realized without implementing complex permission models on the application level.

The advantages of ACLs are clearly evident in situations such as the replacement of a Windows server by a Linux server. Some of the connected workstations may continue to run under Windows even after the migration. The Linux system offers file and print services to the Windows clients with Samba.

Given than Samba supports access control lists, user permissions can be configured both on the Linux server and in Windows with a graphical user interface (only Windows NT and later). With winbindd, it is even possible to assign permissions to users that only exist in the Windows domain without any account on the Linux server. On the server side, edit the Access Control Lists using getfacl and setfacl.

Definitions

User class The conventional POSIX permission concept uses three classes of users for assigning permissions in the file system: the owner, the owning group, and other users. Three permission bits can be set for each user class, giving permission to read ( r ), write ( w ), and execute ( x ). An introduction to the user concept in Linux is provided in the User Guide in Users and Access Permissions . Access ACL The user and group access permissions for all kinds of file system objects (files and directories) are determined by means of access ACLs. Default ACL Default ACLs can only be applied to directories. They determine the permissions a file system object inherits from its parent directory when it is created. ACL entry Each ACL consists of a set of ACL entries. An ACL entry contains a type (see Table B.1), a qualifier for the user or group to which the entry refers, and a set of permissions. For some entry types, the qualifier for the group or users is undefined.

Handling ACLs

The following section explains the basic structure of an ACL and its various characteristics. The interrelation between ACLs and the traditional permission concept in the Linux file system is briefly demonstrated by means of several figures. Two examples show how you can create your own ACLs using the correct syntax. In conclusion, find information about the way ACLs are interpreted by the operating system.

Structure of ACL Entries

There are two basic classes of ACLs: A minimum ACL merely comprises the entries for the types owner, owning group, and other, which correspond to the conventional permission bits for files and directories. An extended ACL goes beyond this. It must contain a mask entry and may contain several entries of the named user and named group types. Table B.1 provides a summary of the various types of ACL entries that are possible.

The permissions defined in the entries owner and other are always effective. Except for the mask entry, all other entries ( named user , owning group , and named group ) can be either effective or masked. If permissions exist in one of the above-mentioned entries as well as in the mask, they are effective. Permissions contained only in the mask or only in the actual entry are not effective. The example in Table B.2 demonstrates this mechanism.

ACL Entries and File Mode Permission Bits

Figure B.1 and Figure B.2 illustrate the two cases of a minimum ACL and an extended ACL. The figures are structured in three blocks — the left block shows the type specifications of the ACL entries, the center block displays an example ACL, and the right block shows the respective permission bits according to the conventional permission concept as displayed by ls -l , for instance.

In both cases, the owner class permissions are mapped to the ACL entry owner . Equally, other class permissions are mapped to the respective ACL entry. However, the mapping of the group class permissions is different in both cases:

Figure B.1: Minimum ACL: ACL Entries Compared to Permission Bits

In the case of a minimum ACL — without mask — the group class permissions are mapped to the ACL entry owning group . This is shown in Figure B.1. In the case of an extended ACL — with mask — the group class permissions are mapped to the mask entry. This is shown in Figure B.2. Figure B.2: Extended ACL: ACL Entries Compared to Permission Bits This mapping approach ensures the smooth interaction of applications with ACL support and those without ACL support. The access permissions that were assigned by means of the permission bits represent the upper limit for all other «fine adjustments» made by means of ACLs. All permissions not reflected here were either not set in the ACL or are not effective. If permission bits are changed, this is also reflected in the respective ACL and vice versa. A Directory with Access ACL The handling of access ACLs is demonstrated in three steps by means of the following example: Creating a file system object (a directory in this case) Modifying the ACL Using masks Before you create the directory, use the umask command to determine which access permissions should be masked from the outset: The command umask 027 sets the default permissions by giving the owner the full range of permissions ( 0 ), denying the group write access ( 2 ), and giving other users no permissions at all ( 7 ). umask actually masks the corresponding permission bits or turns them off. For details, consult the corresponding man page ( man umask ). This should create the mydir directory with the default permissions as set by umask . Use the following command to check if all permissions were assigned correctly: drwxr-x— . tux project3 . mydir Check the initial state of the ACL and insert a new user entry and a new group entry. The output of getfacl precisely reflects the mapping of permission bits and ACL entries as described in B. The first three output lines display the name, owner, and owning group of the directory. The next three lines contain the three ACL entries owner , owning group , and other . In fact, in the case of this minimum ACL, the getfacl command does not produce any information you could not have obtained with ls . Your first modification of the ACL is the assignment of read, write, and execute permissions to an additional user jane and an additional group djungle . The option -m prompts setfacl to modify the existing ACL. The following argument indicates the ACL entries to modify (several entries are separated by commas). The final part specifies the name of the directory to which these modifications should be applied. Use the getfacl command to take a look at the resulting ACL. In addition to the entries initiated for the user jane and the group djungle , a mask entry has been generated. This mask entry is set automatically to reduce all entries in the group class to a common denominator. Furthermore, setfacl automatically adapts existing mask entries to the settings modified, provided you do not deactivate this feature with -n . mask defines the maximum effective access permissions for all entries in the group class . This includes named user , named group , and owning group . The group class permission bits that would be displayed by ls -dl mydir now correspond to the mask entry. drwxrwx—+ . tux project3 . mydir The first column of the output now contains an additional + to indicate that there is an extended ACL for this item. According to the output of the ls command, the permissions for the mask entry include write access. Traditionally, such permission bits would mean that the owning group (here project3 ) also has write access to the directory mydir . However, the effective access permissions for the owning group correspond to the overlapping portion of the permissions defined for the owning group and for the mask — which is r-x in our example (see Table B.2). As far as the effective permissions of the owning group are concerned, nothing has changed even even after the addition of the ACL entries. Edit the mask entry with setfacl or chmod . ls -dl mydir getfacl mydir After executing the chmod command to remove the write permission from the group class bits, the output of the ls command is sufficient to see that the mask bits must have changed accordingly: write permission is again limited to the owner of mydir . The output of the getfacl confirms this. This output includes a comment for all those entries where the effective permission bits do not correspond to the original permissions, because they are filtered according to the mask entry. Of course, the original permissions can be restored at any time with chmod : ls -dl mydir getfacl mydir A Directory with a Default ACL Directories can be equipped with a special kind of ACL — a default ACL. The default ACL defines the access permissions all objects under this directory inherit when they are created. A default ACL affects subdirectories as well as files. Effects of a Default ACL There are two different ways in which the permissions of a directory’s default ACL are handed down to the files and subdirectories in it: A subdirectory inherits the default ACL of the parent directory both as its own default ACL and as an access ACL. A file inherits the default ACL as its own access ACL. All system calls that create file system objects use a mode parameter that defines the access permissions for the newly created file system object: If the parent directory does not have a default ACL, the permission bits as defined by the umask are subtracted from the permissions as passed by the mode parameter, with the result being assigned to the new object. If a default ACL exists for the parent directory, the permission bits assigned to the new object correspond to the overlapping portion of the permissions of the mode parameter and those that are defined in the default ACL. The umask is disregarded. Application of Default ACLs The following three examples show the main operations for directories and default ACLs: Creating a default ACL for an existing directory Creating a subdirectory in a directory with default ACL Creating a file in a directory with default ACL Add a default ACL to the existing directory mydir : The option -d of the setfacl command prompts setfacl to perform the following modifications (option -m ) in the default ACL. Take a closer look at the result of this command: getfacl returns both the access ACL and the default ACL. The default ACL is formed by all lines that start with default . Although you merely executed the setfacl command with an entry for the djungle group for the default ACL, setfacl automatically copied all other entries from the access ACL to create a valid default ACL. Default ACLs do not have an immediate effect on access permissions. They only come into play when file system objects are created. These new objects inherit permissions only from the default ACL of their parent directory. In the next example, use mkdir to create a subdirectory in mydir , which will «inherit» the default ACL. As expected, the newly-created subdirectory mysubdir has the permissions from the default ACL of the parent directory. The access ACL of mysubdir is an exact reflection of the default ACL of mydir , just as the default ACL that this directory will hand down to its subordinate objects. Use touch to create a file in the mydir directory: ls -l mydir/myfile getfacl mydir/myfile Important in this example: touch passes on mode with the value 0666 , which means that new files are created with read and write permissions for all user classes, provided no other restrictions exist in umask or in the default ACL (see B). If effect, this means that all access permissions not contained in the mode value are removed from the respective ACL entries. Although no permissions were removed from the ACL entry of the group class , the mask entry was modified to mask permissions not set via mode . This approach ensures the smooth interaction of applications, such as compilers, with ACLs. You can create files with restricted access permissions and subsequently mark them as executable. The mask mechanism makes sure that the respective users and groups are assigned the permissions they are granted in the default ACL. The ACL Check Algorithm The following section provides brief information on the check algorithm applied to all processes or applications before they are granted access to an ACL-protected file system object. As a basic rule, the ACL entries are examined in the following sequence: owner , named user , owning group or named group , and other . The access is handled in accordance with the entry that best suits the process; permissions do not accumulate. Things are more complicated if a process belongs to more than one group and would potentially suit several group entries. An entry is randomly selected from the suitable entries with the required permissions. It is irrelevant which of the entries triggers the final result «access granted». Likewise, if none of the suitable group entries contains the correct permissions, a randomly selected entry triggers the final result «access denied». Outlook As described in the preceding sections, ACLs can be used to implement very complex permission scenarios that meet the requirements of modern applications. The traditional permission concept and ACLs can be combined in a smart manner. However, some important applications still lack ACL support. Except for the star archiver, there are currently no backup applications that guarantee the full preservation of ACLs. The basic file commands ( cp , mv , ls , and so on) do support ACLs, but many editors and file managers (such as Konqueror) do not. When copying files with Konqueror, for instance, the ACLs of these files are lost. When modifying files with an editor, the ACLs of files are sometimes preserved, sometimes not, depending on the backup mode of the editor used: If the editor writes the changes to the original file, the access ACL will be preserved. If the editor saves the updated contents to a new file that is subsequently renamed to the old file name, the ACLs may be lost, unless the editor supports ACLs. With (hopefully) more ACL-enabled applications released over time, Linux systems will be able to benefit from this feature to the full extent. Источник Читайте также:  Windows restarted to install new updates Оцените статью Вам также может понравиться Windows или Linux: Что лучше выбрать? Есть много причин выбирать между Windows и Linux, но Файл владелец изменить linux Команда Chown в Linux Chown Command in Linux (File Установка шлюза по умолчанию linux Настройка сети вручную Содержание Краткое описание Чем разбить диск для linux ИТ База знаний Курс по Asterisk Полезно — Узнать IP — Правообладателям Политика конфиденциальности Контакты