Как изменить права пользователя debian

• Contents

  1. Introduction
  2. Section 2: UNIX permissions explained
     1. Human-readable form
     2. The defaults for new files and directories
  3. Section 3: Modifying file permissions
  4. Section 4: Example scenarios involving chmod
     1. Case 1: Family photos
     2. Case 2: Software and data files for your department at work
     3. Case 3: Classified files
  5. Group file sharing scenarios and the limits of basic UNIX permissions
  6. Access Control Lists in Linux
     1. Default (inherited) ACL
     2. Appendix: Some hints
  7. See also

Introduction

One of the key factors to system security is access permissions control. All modern operating systems support this feature. It allows file owners to restrict who can read, write, execute and otherwise change files, running processes and other parts of the system.

Linux, as every UNIX-like OS, has a built-in file permission control system. It assigns the following attributes to every file on its file system:

• owner — user who owns the file, has unlimited control over it and can change other file attributes

• group — group the file belongs to

• UNIX permissions — a set of rules defining who can do what with the file

To see what user and group you are, run  id -a  in a Shell:

• uid: your user name and id

• gid: your primary group name and id

• groups: all other groups your user belongs to.

If a particular access permission is granted to one your groups, then it will be also be granted to you.

Your effective group id (taken into account when creating files and directories, as explained below), is most of the time set to your primary group id.

Used terms:

file system — an on-disk structure holding descriptions of files (such as the attributes mentioned above, file modification date etc.) and the files’ contents themselves. File systems are contained in disk partitions (also called slices). Most popular file systems today are ext3, xfs and reiserfs. If you run Debian, you probably use ext3. Worth mentioning is the fact that directories (‘folders’) are also considered files, simply containing other files. Therefore, permissions apply to directories, too.

user group — in UNIX-like systems, every user is assigned to some group. Users in the same group may share rights, for example a file’s permissions may be set so that all users in a group can modify its contents.

Section 2: UNIX permissions explained

Having learnt the theory, it’s time to pass on to practice — what do UNIX file permissions look like and how to use them? First of all, let us examine the permissions of an example file. By issuing the following command in Linux console or a terminal emulator:

stat /etc/hostname

you will see a list of file’s attributes. It includes file type (it could also be a directory, a symlink, etc.), file size et cetera and a line like the one quoted below, which is the item of our interest:

Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)

Obviously, the file is owned by the root user (system administrator) and belongs to the root group. After the slash, numeric user IDs are shown — that’s the way they are stored in the filesystem, in order to conserve disk space.

Access field contains an octal number and its human-readable representation (I personally consider the numeric one to be more readable). It is crucial to know what the permission number means. It consists of four digits, ranging from 0 to 7. For now, we shall skip the first one and focus on the last three, as they are used most commonly on every system. In our example, those are 644. Each digit may be a sum of 4, 2 and 1, but not every component has to be included, giving a possible range from 0 to 7. Below is the meaning of the sum components, with Subject being user, group or others, as discussed below.

• 4 — read permission. Subject is allowed to read the contents of the file or list the content of a directory. Directory content is more than the names of the files, sub-directories, and the other filesystem objects held within each directory; it also includes other meta-information such as whether the filesystem object is a file or directory, the permissions associated with the object, and so forth.
• 2 — write permission. Subject may modify file content. With directories, it allows the subject to modify what’s recorded as being in the directory. This means being able to create files within the directory, or equivalently, move files into the directory; delete files from the directory, or equivalently, move files out of the directory; and, because the directory is where there’s a record of the directory content, to modify the permissions of each file or sub-directory contained in the directory.
• 1 — execute permission. Subject may execute the file. Any file may be marked executable; when the content won’t execute an error is reported at runtime. Likewise any file may have execution privileges removed; files with executable content but no permission to execute can’t be run. In the case of directories, execute permission lets the subject traverse through the directory into sub-directories. Note that directory traversal does not require read permission. See the note on path handling below.

Therefore, number 5, for example, would mean: a permission to read and execute, but not to write.

The digits define respectively: owner, group and others’ permissions. Therefore, we can see that, in our example, file owner (root) may write to the file and read its contents, while group ‘root’ and other users (not being root nor a member of group ‘root’) are given the right to read the file.
Now, compare it to file permissions of /etc/shadow (use ‘stat’ again). This file has 0 as the third meaningful digit, so users not being root nor in group ‘shadow’ may not even read the file. You can easily confirm that by running a text editor and trying to open /etc/shadow — you, as a regular user, should not be allowed to see its contents as it contains system-wide passwords (and this is beyond the scope of this little How To).

Human-readable form

Several system tools and graphical programs recognize the idea of a human-readable form — a string of 10 consecutive characters. To see an example, issue the command below:

ls -l /etc

The -l flag tells ls to display file permissions in the left column of output. The full sequence that you might encounter is as follows (although you probably won’t find such files in /etc):

-rwxrwxrwx+

Now, let’s divide this into parts. The first character defines node type, which is — for normal file, d for a directory, l for symbolic link, c for a character device, p for a pseudo-terminal and b for a block device. You will find files, directories and links commonly throughout the filesystem, while devices and pseudo-terminals should only appear in /dev. Then we have 3 chunks, 3 characters each: rwx rwx rwx. They directly correspond to respective digits of permissions: if the permission is enabled, you get a letter, and if not, you get — in place of that letter. In this case, the first rwx means 7 to owner, the second is also 7 for owner’s group, and the third is the world (others) permission. Thus, for example, 640 translates to:

rw-r-----

(rw- for owner, r— for group, — for others). The last column is the + sign. You are unlikely to see it while listing a directory now (it will appear empty), but it means that extended access rules are in effect, so the file’s real permissions are not only what the file access mode says — you can read about ACL below in this howto.

A note on path handling

To access any path in the filesystem, the user (which the particular process is running as) needs at least execute privilege for all its parent directories. Therefore, if you try to access an example file /etc/security/limits.conf, even though it has a mode of 0755 (for the sake of example), it does not necessarily mean you are free to read it. To read the file, you have to be able to ‘execute’ all of its parent directories, so you need execute permission on /etc and /etc/security. If either /etc or /etc/security has permissions set so that you are not allowed to execute it (1), then reading /etc/security/limits.conf will fail. This rule applies anywhere in the filesystem.

The defaults for new files and directories

This section is included primarily for reference and to aid understanding. Default permissions and group assignment are not often changed so it is safe to skim over this section and come back to re-read it for more detail should the need arise.

The permissions associated with newly created files and directories are, for the most part, determined by something called a umask. The umask is a 4 digit octal number that is subtracted from 0777 to produce the default permission associated with objects newly created in the filesystem. The umask of a ‘stock’ Debian system is 0022 which makes the default permissions be 0755 — the owner has all permissions, the group read and execute but not write, and everybody else can read and execute but not write. One would then expect all newly created files to be marked executable but this is prevented because the system call that creates files defaults to creating files that are not executable. Directories on the other hand do have their execute bit set, umask permitting, and so by default can be traversed by all.

The shell umask command can usually be used (without any arguments) to display the current default umask. The umask is set globally by the system administrator in one of various ways; the most elegant is probably the use of the ?PAM pam_umask module in /etc/pam.d/common-session. The system-wide umask may be overridden by each user. This is usually done in ~/.bashrc on a per-user basis, with the shell umask command on a per-process basis, or using the umask(2) system call from within a program.

The user uid (user id number) associated with a newly created file or directory is that of the running process effective uid. In most cases this is the uid of the user who logged in and started the process.

The group associated with a newly created file or directory is the effective group of the running process. This is normally the group named with the username of the logged in user, but can be manually changed (along with the «real» group) on a per-process basis with the newgrp command although this is rarely done.

The first of the 4 octal digits which represent permissions contains the setuid and setgid bits. These can be used to override some of the defaults described above but it is not worth getting into details other than to note that the user private groups project collaboration idiom (see below) depends on the behavior of the setgid bit.

Section 3: Modifying file permissions

This section shows, using an example, the very basic usage of chmod command. Chmod is one of sysadmin’s best friends and the standard tool for manipulating file permissions in various Unices (also works with *BSD and Solaris!). Let’s begin… First of all, create a file for demonstration purposes. In the example, I will be using name testfile. Commands below are to be executed in a terminal emulator or Linux console. You can just copy and paste, and see how it works.

# first of all, create the file using touch command (see 'man touch' for details)
touch testfile
# now, let's see its permissions
stat testfile
# modify the file so that group members and other users can write to it
chmod 666 testfile
# see the new permissions
stat testfile

There is a special case: to clear special bits with directories, you must mention the file mode bits explicitly (in symbolic mode) or by operator numeric mode (in octal description) (see more with: ‘info coreutils, section 27.5 «Directories and the Set-User-ID and Set-Group-ID Bits»)

Have the file permissions changed? You can verify that it actually worked by starting a new session and logging on to another user account, or issuing su username. If you only have one user account, create a new one for testing:

su
(your root password here, to log on to root account and add a test user)
adduser demo
# you can remove this user when you've finished: deluser demo

Now, log on to demo, open testfile (in your regular user’s home directory) and type something in it. Save, and then check with your own user’s account that it contains whatever you may have written. Voila! You may now want to check it with various different permissions. Try chmod with arguments like 644, 640 and so on.

Section 4: Example scenarios involving chmod

You now know how to change file permissions. However, how can they be useful in real life besides letting your buddy leave you a random message in your own text files?

Case 1: Family photos

Situation: You store family photos in directory Photos on your user account. Several other family members use the computer and you want them to be able to access the photos.

Question: How to set directory permissions so that other users can see your files and their content?

Answer: Set the directory to 755 and all files under it to 644:

chmod 755 Photos
# Photos/* means all files in Photos directory
chmod 0644 Photos/*

Case 2: Software and data files for your department at work

• Note on below: ~ means your home directory.

Situation: In your home directory you have a program in ~/AppSoftware/program.bin . It stores your department-specific data files in ~/OurData. The system operator has assigned you and other people in your department a user group ‘mydept’. You want other people from your department to be able to run the provided software and to write the data files. At the same time, other people from outside the group should be allowed to run the software but not to modify the data. For simplicity’s sake, we skip things like logging who added/removed what in terms of data (logging is a necessity in real life), focusing only on appropriate permissions.

Question: How to allow execute access for a group to one file (program binary) and read-write access to other directory for the same group, while denying world (other users) access?

Answer: In our example, this would be:

# below: -R flag, affects the directory and files/subdirs inside
chmod -R 0755 ~/AppSoftware
chmod -R 0770 ~/OurData

In case files have a wrong group attribute set, you can correct it by first running chgrp -R mydept files, where ‘mydept’ is the group name, ‘files’ is file path, and -R switch tells chgrp to run recursively (see above code example). Chgrp changes files’ group to the one given.

Case 3: Classified files

Question: How to protect files that are to be kept secret?

Answer: A very basic protection can be achieved by chmodding the sensitive files/directories to 0600. However, remember that the system administrator (root) can still access them, regardless of set file permissions. Therefore, besides locking down file permissions, it is highly advisable that you encrypt the files using strong encryption software (try OpenPGP encryption via programs like KGpg, or see ccrypt — symmetric cryptography).

Group file sharing scenarios and the limits of basic UNIX permissions

Examples above show the usefulness of UNIX file permissions. You can grant users from your group access to your files, expose them to the whole world or have them only for yourself. However, there are use cases in which this access control model is not enough. Assume that you are on a large system (perhaps a server) and, together with several dozen users you are members of group ‘users’. Now, you want to make some of your files available to just one of them so that the others can not read it. How can UNIX permissions benefit you? You could use the user private groups directory sharing idiom; a common solution to this problem. But the user private groups idiom pushes the UNIX permission system to its limits and there are cases, even simple file sharing cases between 2 people, where the idiom is simply not suitable.

When the limits of basic UNIX file permissions are reached it is time to make use of…

Access Control Lists in Linux

Access Control Lists (called ACL) are an extended means of defining access rights to files and objects. They allow you to specify file permissions in a more fine-grained way, assigning any user or group (besides owner and file’s set group) different privileges. For instance, you may share a file with just one specific user, no matter what group they are in. How to make use of this new, powerful feature?

First, make sure your system supports ACL. Several criteria must be met before you can enable ACL for your files. Check your kernel version. If it is anything later than 2.6.18, then chances are you already have ACL support built-in. (I’m not quite certain at which version Debian kernels received the ACL patch). The next thing is acl package, required for ACL attribute manipulation. You can install it by issuing:

 # if you are not logged on as root, use 'su' first
apt-get install acl

Alternatively, you can use Synaptic package manager, or another package manager, to get and install the package. If you are not the system administrator, ask your sysadmin to enable ACL on your machine.
Once you have installed acl, you can try and see if your file system supports it. Example command (I assume that file ‘testfile’ exists):

setfacl --modify user:demo:5 testfile

If setfacl complains about an error, you probably need to mount your filesystem with acl option. Assuming that the filesystem ‘testfile’ is located on is / , execute the below as root:

mount -o remount,acl /

Try setfacl again. If successful, a call to:

getfacl testfile

should show, among others, a line like this:

user:demo:r-x

Here, rx means ‘read, execute’ permission, which is equivalent to 5. To see if Access Control Lists work, set the file permissions on testfile to 700 using chmod and try to open it from ‘demo’ user account. If successful, ACL did override UNIX permissions indeed. Your file system is now ready for granular access control with ACL!

Note: To enable ACL permanently for certain filesystems, you should include acl option in /etc/fstab. Please refer to fstab(5) manual page for instructions.

Example uses of setfacl to manage file permissions

setfacl -R -m user:josh:6 filedir   # sets read-write permissions for josh on filedir and all its contents
setfacl -m group:junior-sys-admins:4 /var/log/apache2/error.log    # let group members of junior-sys-admins read Apache2 error log file
setfacl -m user:evilcraig:0 my_notes.txt    # prevent user evilcraig from accessing my_notes.txt

Default (inherited) ACL

Note: a bug in coreutils commands cp and mv limits the scope of the below to pure file creation, e.g. with touch: with copy and move, the «Default mask» of the target parent directory won’t be inherited as the «Access mask» for the copied/moved file/directory: http://debbugs.gnu.org/db/85/8527.html

Default ACL are an invaluable tool when making a directory that you want to share for reading or writing among users. This hint is inspired by this thread on the Debian forums: http://forums.debian.net/viewtopic.php?f=10&t=53591

Default ACL are access control entries that get inherited by all sub-items of a directory (recursion deeper is allowed!). Thus, if you want to create a directory for bob and fred so that both can work on each other’s files, the below should suffice (notice the -d flag to setfacl, it sets a default ACL):

mkdir common_workspace
setfacl -m u:bob:7 common_workspace
setfacl -d -m u:bob:7 common_workspace
setfacl -m u:fred:7 common_workspace
setfacl -d -m u:fred:7 common_workspace

Note to the above: a default ACL is inherited by all child nodes as an ACL entry and default ACL, but a default ACL on its own does not take any action permission-wise — hence the double command. The first call gives user ‘bob’ the right to write, read and execute the directory, and the second one sets up the default ACL which will be inherited.

Now, whenever a file gets created, it retains its original owner and group, but should automatically get assigned the above ACL. This is, for example, useful when you have users co-working on website development. You can use Apache or PHP running as www-data, write a script to change file ownership upon creation to www-data (inotify helps!), and all files are still writable by bob and fred, your Web developers.

Appendix: Some hints

• On Debian systems, every user is traditionally assigned their own group. File sharing may be accomplished by adding one user to other’s group, as shown below (only to be done as root):

  adduser me otherguy # adds user 'me' to group 'otherguy'

Then, ‘otherguy’ can just set their files to 0750 or whatever permissions they want you to have. However, this is the old-fashioned approach to granular file permissions and should be avoided whenever possible in favour of user private groups or ACLs.

• Konqueror (at least in Debian Squeeze) supports ACL out-of-the-box when filesystems are mounted with acl option. It allows for easy, graphical management of extended access rights, similar to that of Microsoft Windows.

• Sometimes you have to mount a filesystem that does not support ACL. For example, a NFS volume exported by a central storage solution, or an userspace zfs diskset. In these situations, you can try one simple solution: http://cintrabatista.net/nfs_with_posix_acl.html

• You can find a wonderful but pretty old (still current, though) ACL guide here: http://www.vanemery.com/Linux/ACL/linux-acl.html

That’s all! Have fun and thanks for bearing with me.

See also

• DebianSecurity

• DebianSecurity/AdvisoryCreation

• Use Aptitude to restore an installed package permissions to their default

• SecurityManagement

• Teams/Security

CategoryCommandLineInterface | CategorySystemSecurity | CategorySystemAdministration | ToDo: refactor

Предлагаю вашему вниманию третью статью из серии статей-шпаргалок, главная задача которых — быстрое освежение в памяти необходимой информации. На этот раз речь зайдет о правах доступа к файлам и каталогам. Как всегда информация не представляет из себя что-то уникальное и найти её можно как на других блогах или форумах, так и на справочных страницах.

Отобразить права доступа на объекты можно с помощью команды «ls» с ключом «-l«, при выводе мы увидим что-то на
подобии этого (права доступа выделены красной рамкой):

Далее идет пользователь-владелец объекта и основная группа пользователя. Подробнее о выводе команды «ls» вы можете почитать в «манах» или в моей предыдущей статье «Debian. Шпаргалка сисадмина. Работа с файлами и каталогами«.

Первый символ означает тип объекта, ниже они собраны в таблицу:

Для изменения прав доступа используется команда «chmod«. Права доступа могут быть заданы в символьном или абсолютном виде.

Формат символьного режима:
`[ugoa…][[+-=][rwxXstugo…]…][,…]’.
Буквы «ugoa» расшифровываются следующим образом, как логично предположить:
u — пользователь-владелец;
g — первичная группа пользователя, в неё также могут входить другие юзеры;
o — все остальные пользователи, не входящие в первичную группу пользователя-владельца;
a — все вышеперечисленные (a=ugo).

Далее разбираемся с «+-=«:
+ — добавляет выбранные права доступа к уже имеющимся;
— — удаляет выбранные права;
= — присваивает только выбранные права каждому указанному файлу.

Теперь перейдем к правам:
r — чтение;
w — запись;
x — выполнение (или доступ к каталогу);
X — выполнение, если файл является каталогом или уже имеет право на выполнение для какого-нибудь пользователя;
s — setuid- или setgid-биты;
t — sticky-бит;
u — установка для остальных таких же прав доступа, которые имеет пользователь, владеющий этим файлом;
g — установка для остальных таких же прав доступа, которые имеет группа файла;
o — установка для остальных таких же прав доступа, которые имеют остальные пользователи (не входящие в группу файла).

Небольшое пояснение по поводу параметра «t«, цитата из справочных страниц:

В настоящее время установка sticky-бита для каталога, приводит к тому, что только владелец файла и владелец этого каталога могут удалять этот файл из каталога. (Обычно это используется в каталогах типа /tmp, куда все имеют права на запись)

Биты setuid— и setgid нужны чтобы запускать исполняемые файлы от имени пользователя-владельца. Если запустить исполняемый файл, который находится в каталоге с установленным битом setgid, то файл запустится с идентификатором группы-владельца этого каталога.

С правами доступа в абсолютном виде дело обстоит следующим образом: для каждого объекта безопасности можно задать права в виде rwx, где r — чтение, w — запись, x — выполнение; соответственно, если права необходимо предоставить, выставляем «1«, если права не нужны — «0«. Таким образом полные права для пользователя в двоичной системе счисления будут выглядеть как «111«, что в восьмеричной будет равно 7.

Рассмотрим на примере как в двоичном виде будут выглядеть маска полных прав для владельца, прав на чтение и выполнение для первичной группы и права на чтение для всех остальных:
-rwxr-xr—
111101100
Теперь условно разбиваем на 3 части:
111|101|100
Переводим в восьмеричную систему и получаем:
754

Стоит отметить, что в большинстве случае биты setuid-, setgid и sticky в абсолютном виде опускаются. Чтобы их установить, необходимо перед числовым представлением прав вставить 4 для setuid, 2 для setgid и 1 для sticky.

Теперь попробуем задать одни и те же права в символьном и абсолютном виде.

Задать владельцу полные права, группа и остальные пользователи не имеют никаких прав, даже на чтение:
root@debian7:~# chmod u=rwx,go= test_file01
Как мы видим, права на файл изменились соответствующим образом:
Аналогичная команда в абсолютном виде выглядит так:
root@debian7:~# chmod 700 test_file01

Задать владельцу полные права, группе права на чтение и изменение, а всем остальным на чтение и выполнение:
root@debian7:~# chmod u=rwx,g=rw,o=rx test_file01
Аналог в абсолютном виде:
root@debian7:~# chmod 765 test_file01

Стоить отметить, что основное преимущество изменения прав с использованием символьного вида состоит в гибкости этого метода — он позволяет изменять права только определенным объектам безопасности.

Например, мы имеем файл c разрешениями для владельца только на запись и чтение, а у всех остальных никакого доступа нет. Мы хотим присвоить группе и всем остальным право за чтение файла. Сделать это можно командой:
root@debian7:~# chmod go+r test_file01
При этом мы никак не меняем права пользователя, потому что они нас устраивает, а изменяем права только группы и всех остальных.
Чтобы задать такие же права в абсолютном виде, нам придется задавать их для каждого объекта безопасности:
root@debian7:~# chmod 644 test_file01

Теперь попробуем у этого же файла изменить права следующим образом: владельцу дать дополнительно права на выполнение, группе дать права на запись, а права на чтение у всех остальных отозвать:
root@debian7:~# chmod u+x,g+w,o-r test_file01
В принципе эту же команду можно записать даже немного короче:
root@debian7:~# chmod u+x,g+w,o= test_file01
Аналог в абсолютном виде:
root@debian7:~# chmod 760 test_file01

Выставим файлу, например, бит setuid:
root@debian7:~# chmod u+s test_file01
Аналогичная команда в абсолютном представлении с текущими правами:
root@debian7:~# chmod 4760 test_file01
Соответствующим образом изменились и права:
(см. скриншот 06)

Sticky-бит можно установить вот так:
root@debian7:~# chmod +t test_file01
В абсолютном представлении с сохранением текущих прав:
root@debian7:~# chmod 1760 test_file01

Если есть необходимость установить враз, например, setuid и sticky, то маска будет 4+1=5 (или 100+001=101).

Если нужно изменить права рекурсивно на каталог:
root@debian7:~# chmod -R 755 testdir02

Либо на все файлы в текущем каталоге:
root@debian7:~# chmod -R 755 *

Кроме изменения прав доступа может потребоваться смена пользователя-владельца или группы. К сожалению, «chmod» это сделать не сможет, однако есть другие команды:

chown — изменить владельца и группу файлов.

Пример использования:
chown [опции] пользователь[:группа] файл…
root@debian7:~# chown zabbix:zabbix test_file01
Можно использовать рекурсию для изменения владельца всех файлов и каталогов:
root@debian7:~# chown -R zabbix:zabbix testdir02

chgrp — изменить группу файлов

Изменим группу у файла:
root@debian7:~# chgrp zabbix test_file01
Или рекурсивно для каталога:
root@debian7:~# chgrp -R zabbix test_file01

На этом обзор основ работы с правами закончен. Более подробную информацию можно найти в разделе «1.2.3. Filesystem permissions» руководства.

При написании статьи использовались следующие источники, кроме упомянутых выше:

Linux chmod command sticky bit example and implementations

Права доступа Unix, SUID, SGID, Sticky биты

CHMOD(1)

comments powered by HyperComments

В этой статье изучим стандартные права доступа к файлам в Linux. Научимся одним пользователям давать доступ к файлам, а у других его забирать.

Права доступа к файлам

Debian или Ubuntu – это многопользовательские операционные системы, и у разных пользователей разные права. Например, один пользователь может читать и создавать одни файлы, а второй может делать тоже самое но с другими файлами, ну а третий пользователь сможет проделать это и с первыми и со вторыми файлами.

Помимо чтения и редактирования файлов, их возможно запускать, если это файлы программ или скрипты.

Получается, с файлами можно делать три стандартные действия: читать (r), редактировать (w), запускать (x). Это и есть стандартные права доступа к файлам в Linux.

Дополнительно, документацию для Debian по правам доступа, на английском языке, можете почитать тут.

Права доступа к каталогам

В Linux все является файлами и каталоги это тоже файлы, об этом я рассказывал в этой статье. С каталогами можно выполнять те же действия, что и с файлами:

• прочесть каталог (r), то есть посмотреть список файлов, например с помощью утилиты ls;
• отредактировать каталог (w):
  • создать новый файл, например с помощью mkdir или touch;
  • удалить файл с помощью rm;
  • переместить файл в другой каталог с помощью mv;
• войти в каталог, другими словами сделать его текущем (x) можно с помощью утилиты cd.

Это стандартные права доступа к каталогам в Linux.

Кто выполняет действия над файлами

С возможными действиями над файлами и каталогами мы разобрались, теперь разберемся с теми, кто может эти действия совершать:

• владелец файла или каталога (u). Владельцем файла является тот, кто его создал, или получил право владения им;
• группа владельцев файла или каталога (g). Файл получает группу владельцев от первичной группы создателя файла, или группу владельцев может назначить пользователь root;
• все остальные (o);
• a — все пользователи (a). Владелец и группа владельцев и все остальные вместе взятые.

Таким образом получается такая система прав u=rwx / g=rwx / o=rwx. То-есть, что может делать с файлом его владелец, что может делать с файлом группа владельцев и что могут делать с файлом все остальные.

Смотрим права файлов и каталогов

Права файлов и каталогов можно посмотреть с помощью команды ls -l. Можно добавить опцию -d чтобы смотреть права каталога, не спускаясь в этот каталог. Команда ls показывает права таким образом rwxr-xr-x, первые три символа это права для владельца, следующие для группы, следующие для всех остальных.

Давайте, для примера, создадим каталог test и посмотрим какие права он получил в Debian и в Ubuntu:

alex@ubu:~$ mkdir test
alex@ubu:~$ ls -ld test/
drwxrwxr-x 2 alex alex 4096 янв 19 10:04 test/

alex@deb:~$ mkdir test
alex@deb:~$ ls -ld test/
drwxr-xr-x 2 alex alex 4096 янв 19 13:05 test/

Разница между Ubuntu и Debian в том что, по умолчанию, каталог в Ubuntu создается с такими правами rwxrwxr-x, а в Debian с такими rwxr-xr-x. Это означает что в Debian пользователи входящую в группу владельцев этого каталога не смогут ничего удалить или создать в этом каталоге, а в Ubuntu смогут.

А после прав, в выводе ls -l, идут Владелец файла и Группа владельцев (alex alex).

Создадим файлы в каталоге и посмотрим на их права:

alex@ubu:~$ touch test/file1.txt
alex@ubu:~$ touch test/file2.txt
alex@ubu:~$ ls -l test/
total 0
-rw-rw-r-- 1 alex alex 0 янв 19 10:12 file1.txt
-rw-rw-r-- 1 alex alex 0 янв 19 10:12 file2.txt

alex@deb:~$ touch test/file1.txt
alex@deb:~$ touch test/file2.txt
alex@deb:~$ ls -l test/
итого 0
-rw-r--r-- 1 alex alex 0 янв 19 13:12 file1.txt
-rw-r--r-- 1 alex alex 0 янв 19 13:12 file2.txt

Права на файлы в Ubuntu (rw-rw-r–) и в Debian (rw-r–r–) тоже немного отличаются. В Debian группа владельцев не может редактировать файл в отличии от Ubuntu.

Для назначения прав используют две утилиты:

• chmod для настройки прав (rwx);
• chown для смены владельца и группы владельцев файла.

Настраиваем права — chmod

Синтаксис этой команды такой:

# chmod [ugoa] [+-=] [rwx] <file>
u - владелец
g - группа
o - все остальные
a - все

Знак “+” добавляет право, знак “–” отнимает право, знак “=” устанавливает право для выбранной категории пользователей, убирая все остальные.

С прошлого урока у меня остался пользователь testuser:

alex@deb:~$ id testuser
uid=1001(testuser) gid=1001(testuser) группы=1001(testuser)

Сделаем так, чтобы каталог test не могли читать все остальные и попробуем прочитать этот каталог под пользователем testuser:

alex@deb:~$ chmod o-r test/

alex@deb:~$ su testuser
Пароль:

testuser@deb:/home/alex$ ls -l test/
ls: невозможно открыть каталог 'test/': Отказано в доступе

Командой chmod мы можем устанавливать права и отбирать их, я указал o-r, что означает у всех остальных (o) отнять (-) права на чтение (r).

Устанавливать права может либо владелец файла, либо пользователь root.

Но зайти в каталог testuser все равно сможет:

testuser@deb:/home/alex$ cd test/

testuser@deb:/home/alex/test$ cd -
/home/alex

Теперь попробуем прочитать каталог под пользователем alex:

testuser@deb:/home/alex$ exit
exit

alex@deb:~$ ls -l test/
итого 0
-rw-r--r-- 1 alex alex 0 янв 19 13:12 file1.txt
-rw-r--r-- 1 alex alex 0 янв 19 13:12 file2.txt

Вот несколько примеров работы с командой chmod:

$ chmod o-rwx #забрать права на чтение, запись и исполнение для всех остальных
$ chmod o+rwx #дать права на чтение, запись и исполнение для всех остальных
$ chmod g+rx  #дать права для группы владельцев на чтение и исполнение
$ chmod a+r   #всем дать право на чтение
$ chmod ug+rw #владельцу и группе дать право на чтение и запись
$ chmod o=x   #всем остальным мы назначаем права на исполнение, rw удаляются если были

То есть мы вначале говорим кто (u или g или o или a), дальше указываем что сделать (– удалить право, + добавить право, = установить право), дальше указываем права (r или w или x, или их комбинации). При этом “+” отличается от “=” тем что, “+” добавляет право к уже имеющемся, а “=” заменяет.

Числовые значения прав

У прав есть числовые значения: r=4, w=2, x=1. Для удобства я подготовил следующую табличку:

Используя chmod можно устанавливать права в числовых значениях, при этом нужно указывать сумму прав. Например права rw-r–r– в числовом формате будут такими 644, то есть мы сложили права для владельца (r+w=6), дальше для группы и для всех остальных (r=4).

Вот как назначают права в числовом виде:

alex@deb:~$ chmod 644 test/file1.txt

alex@deb:~$ ls -l test/file1.txt
-rw-r--r-- 1 alex alex 0 янв 19 13:12 test/file1.txt

Смена владельца и группы владельцев — chown

Теперь нужно разобраться, как менять владельцев у файлов, для этого нужно использовать утилиту chown. Владельца сможет сменить только суперпользователь.

alex@deb:~$ su -
Пароль:
root@deb:~# chown testuser:testuser /home/alex/test/
root@deb:~# ls -ld /home/alex/test/
drwxr-x--x 2 testuser testuser 4096 янв 19 13:12 /home/alex/test/

alex@ubu:~$ sudo su -
[sudo] password for alex:
root@ubu:~# chown testuser:testuser /home/alex/test/
root@ubu:~# ls -ld /home/alex/test/
drwxrwx--x 2 testuser testuser 4096 янв 19 10:12 /home/alex/test/

Так как в Ubuntu не задан пароль для root пользователя я использую sudo чтобы переключиться на него. Это я уже разбирал в этом курсе.

Команде “chown” нужно указать имя пользователя, потом двоеточие и имя группы. После проделанного пользователь testuser и группа testuser станут владельцами данного каталога.

Можно сменить только владельца а группу не менять:

root@deb:~# chown alex /home/alex/test/

root@deb:~# ls -ld /home/alex/test/
drwxr-x--x 2 alex testuser 4096 янв 19 13:12 /home/alex/test/

А можно сменить только группу владельцев:

root@deb:~# chown :testuser /home/alex/test/

root@deb:~# ls -ld /home/alex/test/
drwxr-x--x 2 alex testuser 4096 янв 19 13:12 /home/alex/test/

Как вы помните пользователь testuser не мог прочитать каталог test/, теперь он это сделать может, так как для группы у нас есть право читать этот каталог.

root@deb:~# su testuser

testuser@deb:/root$ ls /home/alex/test/
file1.txt  file2.txt

testuser@deb:/root$ exit
exit

root@deb:~#

Рекурсивная смена прав и владельцев

Команды chmod и chown умеют работать рекурсивно, то есть изменять права на каталог, спуститься в этот каталог и изменить права на все файлы в нем, если в нем есть подкаталоги то пробежаться и по ним.

Для этого используется опция -R:

root@deb:~# chmod -R 644 /home/alex/test/
root@deb:~# chown -R alex:testuser /home/alex/test/

root@deb:~# ls -l /home/alex/test/
итого 0
-rw-r--r-- 1 alex testuser 0 янв 19 13:12 file1.txt
-rw-r--r-- 1 alex testuser 0 янв 19 13:12 file2.txt