The rights of access to files

Any UNIX, and in particular FreeBSD - multiuser system, it provides a mechanism to restrict user access to files and directories.
"Access" means not only an opportunity to read or modify the contents of individual files, but also the ability to create files (directoriess), delete them, run executable files (if they are executed), to change its name and change all the attributes which determine " right of access ", i.e. -" who "can do with this file or directory.

Firstly, it should be noted that more correct to speak not about the "user rights" in relation to any file, but about the "rights of progress” (executable program).
First, if the user makes any changes to the files or directories, he does it with the help of some programs (editors, "commanders", system utilities to copy, delete files, etc.), which at the time of execution is the process.
Secondly (more importantly), not all programs run by users manually. Some of them ( demons ) are run at system startup. Others are able to run at certain times (using cron program), or called as needed to service requests coming from the network (usually launches a "manager" inetd). In addition, there are several programs that are for performing some auxiliary action themselves run other programs (in this case we say that the process, "parent" started the process, "descendant"). Obviously, these programs (processes) should be restricted in access to files.
And finally, thirdly, in some cases very useful when program launched by the user, had more rights than is usually the user. For example, a typical user can not even read the file, in which the "hidden" passwords for all users. At the same time, any user should be able to change their personal password without resorting to this administrator. But for this he should be able to write something in the password file. So a program that does it (passwd) at the time of execution should be entitled to much more than the user who runs it.
- Each process has a user ID (userID). Usually, it coincides with userID of user who started this process;
- Processes that start automatically have userID too as if they ran by real user. Whose is userID receive these programs are usually determined by the programs that they start (a program loader, cron, inetd, etc.). In the simplest cases, the program, "descendants” just "inherit" userID from the program, "parent", but some "parents" can run the program with other userID (not coinciding with his own);
- Some programs in the process of implementation can change its userID and, accordingly, to obtain the rights that the user did not have. Naturally, to ensure that the program could do this, the administrator must "allow" it to such behavior. Change userID done not only when you need to "expand" the right of program, but on the contrary - "restrict" to the rights of any individual user;
- If the process can change its userID, then there are "real userID" and "effective userID" (there is also "saved userID"). Real userID is an identifier of the user who started the process (or userlD of a "parent" process). An effective is a new userlD that the problem recieved at the time of execution;
- Rights to file (or directory) are determined by "effective userlD" process. In the simplest case, when userlD is not changed, "real" and "effective" userIDs coincide and we can speak only about userlD of process. Or even about the rights of the user (and not the process) to file.
What are the attributes of a file thatdetermine the "right of access.
All users for each file (or directory) are divided into three categories
1) the owner of the file;
2) the group of "specially committed" to the file;
3) all others.

It means that you can set three different "tolerance" (a set of access rights) for each file or directory. One such set will define the rights of the user who owns the file, another set will define the rights of users who belong to a certain group, but are not owners, and finally a third set establishes the right for all other users who do not belong to this group " specially committed" and are not the owner of the file.
Consequently, each file (directory), there are three attributes that are stored somewhere in the file header and regulate access to it. Attributes for the file are more than three. By attributes include the file name, size, creation time, etc. But in this case we are interested in only these three,
In the file header is written user ID (userlD), which is considered its owner. "Owner" can be only one specific user.
In addition, the attributes stored group identifier (groupID), which determines the group " specially committed", as described above. Each group (its name is a numeric identifier - groupID and composition) is determined by the system administrator. I.e. "ordinary" user, even if he is the owner of the file, can not arbitrarily make a list of "friends" whom he trusts special rights in relation to its file. He can only choose a suitable group of available (and then only if he enters into this group).
In the file attribute there is a set of bits, or "flags", which indicates - who and what can be done with this file. This set is called permissions, which can be translated as "tolerances" or "right of access”

Type command

Ls-l

-rw-r—г- 1 bob users 4297 23мар 17:37 list_us

-rwxr-xr-x 1 bob users 1502 17мар 12:03 myProg

-rw-r—-r- 1 bob users 5354 12мар 23:51 tmp.dat

\________/ \_/ \_____________/ \_________/ \______/

“rights”, owner, group and length, date, file name

In the third column you see the login name of user - "owner" of these files (in this case - bob). In the fourth column - the name of the group, that is also attributed to these files (in this case - users). And in the very first column there is(a set of characters like "g", "w" and "-") permissions themselves for all three categories of users.
In the header of the file is stored, not the names of users and groups, but their numerical numbers, and "right", in fact, are not a chain letter, but a set of binary bits.
During printing the contents of the directory (for example, the command ls) each line has the form

-rw-r--r— 1 bob users 4297 13мар 21:45 filesl

The first column consists of ten symbols. However, the very first sign is not related to permissions but denotes a type of this object. Because, in the directory except the files may be also a subdirectory and, furthermore, in UNIX, in addition to ordinary files, there are other objects ("links", " turns ", "socket", etc.) that are included in the directory and have the attributes as for ordinary files. So, the first symbol just show - what object we see: a regular file (the icon "-"), subdirectory (icon “d”) or some other specific object (“ l “," s "," p "...).
The remaining nine characters represent three groups of three symbols. Each group defines the rights to any of the three categories of users:
- First group - rights of "owner";
- The second group – rights of "group of specially committed";
- The third group - rights of "all others". The meaning of individual bits in each group of "rights" is the same for all three categories of users, so you can examine in detail any such group, without specifying for which category of users it is intended.
However, for files and directories in the meaning of these bits has a little difference, so they should be considered separately.
For files the first bit is denoted by the letter “r” (read), and means that the user, falling within the appropriate category is allowed to read the contents of this file. So, he can see the contents of the file and copy the file. Incidentally, it does not mean that the user can run it (if this program). The second bit, denoted by the letter “w” (write), allowed to write into a file. That means, the user can change the file content (for example, some editor), add something at the end or erase all the contents. Note that this bit do not gives the right to remove the file from a directory or to change its name (it is defined by rights to the directory itself), but it gives an opportunity to make the file empty (zero length) or copy the contents of another file (and thus "replace“ it). Finally, the third bit, denoted by the letter “x” (eXecute), can run on the execution of this file, if it is a program or command file. Please note that it is also the main sign on which the system realizes the "start capability" of the file.

For the directory the first bit ("r") allows you to view contents of this directory, i.e. a list of files and subdirectories that are in it. But this bit will not allow to go to this directory (with the command cd) or gain access to content, i.e., read / run / modify files, even if the "permissions", that are set on the files themselves, allows it. That is why "the right to read the directory” is practically useless, and this bit is usually put together only with a bit of “x”. Few running forward, let consider the third bit - "x". For directories it just means that the user can access the "components", i.e. the individual files and subdirectories. Only if this bit is presented, the system allowed to enter that directory and perform some action with the file if the file itself ("the right of access" to them) allows it. Incidentally, note that even if the internal subdirectories have "normal" rights for some categories of users, and superior directory - no (no bits "x"), then these users will not be able to "dive" into a subdirectory, bypassing the superior. The system checks the full "path" to the end of a directory or file (for example, / usr / share / misc / fonts) and, if at least one component of this path does not have the corresponding bit, then the user will be denied in access. Finally, a “w” bit, set on a directory that allows you to change the contents of the directory. In other words, it allows you to create new files (or copy the other files in that directory), change the file names and delete files.
Pay attention to the "separation of powers" between those permissions, which are on file and those in the directory.
As already mentioned, if directory permissions do not allow the user to delete a file in it (no bits”w "), it does not mean that the user can not" remove the contents of a file (for example with text editor).
On the other hand, if the user has the right to change the contents of the directory, it will be able to delete or rename any file that is in it, even if the rights to the file itself, does not allow him to write to a file and read it.
None of the rights listed here are not related to the changes of “access attributes " themselves, i.e. - the file owner, group and permissions. Their change is subject to other laws, which will be discussed below.
All these bits have no effect for the user root (and programs that have changed during the execution of its "effective userlD" to "route"). I.e. he can do with a file or directory all he wants.
Since the bit "x" on a file is a basic feature of "execution" the file, even root will not be able to convince the system that the file is a program and it can be performed, until this bit will be put in the attributes.

Additional bits access
In addition to the above mentioned bits (read, write and “execute "), which are set separately for three categories of users, there exist three more bits of access, which can be attributed to the file as a whole, since their action does not depend on which user (in the sense of what category) tries to access a file. And the meaning of these bits is not to restrict access to the file (directory). They change some properties of files or directories.

Bit suid

It stands for “Set user ID”. Поскольку подходящего русскоязычного термина не существует, его обычно называют "суидный" бит, а файлы, на которых он установлен — "суидными". Я не знаю, нужно ли это предложение в англоязычной методичке???

Its meaning is that if it is installed on a file, which is a program then when it is executed, it automatically changes the "effective userlD" to the ID of the user who owns the file. That is, no matter - who runs this program, she has carried out has the right to host this file.
Usually this is done to enable the user to perform actions that require privileges of root (for example, change your password). Naturally, the owner of such a program must be user root.
It is clear that such a program is "potentially dangerous". In "normal" case, it will not allow normal user to do something that is beyond its powers (for example, passwd program will allow the user to change only your own password, but not the passwords of other users). But even a small mistake in such a program could lead to the fact that the "attacker" can force her to perform any more actions not provided by the author of the program. In such file permissions look like **s****** (if a bit x is set for the owner) or as ** S ****** (if a bit x not installed). However, to set suid bit on the non-executable files usually do not make any sense (at least in FreeBSD). But there are programs that check this bit even for text files. Also, this bit does not carry any meaning, if it is put to the directory, but no one forbids it to do.
Beat sgid
Stands for Set group ID.
Its meaning is similar to the meaning of the previous bit. Just the user ID does not changes and group ID changes. That means, during the performance of this file it has such rights, as if he ran by someone of the group, which is assigned to this file.
Permissions of this file looks like ***** s *** (if bit x is installed for the group) or ***** S ** (if the corresponding bit x is not installed). As in the previous case, the sgid bit for non-executable file does not make any sense.
Sgid bit on directories.
For FreeBSD (and other BSD-systems), this bit again, has no effect. But in some other Unix-like systems, it means that when files are created in a such directory, in their attributes Such grour is placed that is the same as that of the directory. In other words, files created in this directory "inherit" the group from the directory.

Sticky bit.

It looks in permissions, as ******** t (if, together with an x bit for the "all others") or ******** x (if the corresponding x bit is absent).
For directories of its meaning lies in the fact that to remove a file from a directory (or rename) may only file owner. In the normal case (without a bit) the ability to delete files (and create) is determined by write rights (bit w) on the directory. That is, if a user belongs to the category for which writing to the directory is permitted, he can remove in it any file, regardless of the attributes (owner, group, permissions) of the file itself.
This bit is usually applied in directories that are "public" (for example, /tmp). These directories have permissions that allow all users to create there their own files and delete them. But it would be wrong, that any user can by mistake or “out of wickedness” delete files to which it has no relation. In order to prevent the possibility of removing the file by "outsider" users, a sticky bit is serves.

This bit can be placed also on the executable files. In this case, it means that the file, even after the completion of the work must remain in the memory (of course, not in RAM, but in swap).
This is useful for frequently used executable files of common use. In practice, these files are very rare. It is possible, practically it is not used by anybody.

Combinations of bits of access

For files
Usually, the right to file (for example, for "all others") are set as:
--- No rights (you can not read or modify content);

- r. read only;
rw - read and write (change) file.
If the file is "executable", then the rights may look like:
---Again, no rights (can not read, can not run);

- r-x can run a file-task to perform;
rwx you can not only run, but change something in it.

The other combinations (for example,- w - or – x)seem pointless.
However, it is not always the same way. Let consider it in details.

Rights and - w - means that the user of the respective category can not read the file, but can he write in it.
Rights –x, actually a legitimate combination. It means that this task can be run (and get some sort of result of it). We can not just copy the file itself or "climb" in it by debugger.
Therefore, these permissions even useful if you want to keep your "intellectual property". Combination

-wx, perhaps, has no meaning (as just-w-on the executable file). You just give the opportunity to change the contents, and "blindly" (as review this content is restricted). The result can only be damage to your file.
Also r—rights can be attributed to meaningless in the executable file. Another user could easily copy the file itself, it will become full owner of the copy. Then he put on his copy such rights, that he wants and in the end start it.
For directories
For the directories access rights are usually established:

--- no rights;
r-x normal rules for "visits" directory, but without the right to change (create / delete / rename files);

rwx full access (do there what you want).

Remark
If there is no access bit-x (to access content), then any combination of the other two will not give anything useful.
The combination r-- enable a list of files in this directory, for example with command ls and nothing more. And you can see only the file names, and such details as the owner / group / permissions will be unavailable. You can not "enter" in such a directory by command cd. And, even if the inside subdirectories are quite normal access rights (for example, r-x), to get to them would be impossible.
Combinations- w - and rw - have even less sense. Anyway, it is impossible to change something in a directory with such access rights.
But a combination of --x and -wx actually are quite sensible.
In this way you can make a "semi-secret" directory. "Secrecy" of it is that nobody else can see - that the files and directories in it. But if you tell your friends the file`s name, they can easily get it out or watch it.
Similarly, with subdirectories. If you do not want someone to just "wandering" on your directories came across a folder with a "secret" content, but at the same time, do not mind that some close friends were there "rife" and get acquainted with new replacements, "hide "their" private "directory to the directory (for example private) to access – x.
Then your friends can get into a necessary subdirectory, specifying the full path (cd private / pictures), but casual visitors simply do not find (unless, of course, the visitor does not root).
Of course, the "secrecy" in this case is not complete, since, if an outsider somehow will know the correct name of the file or subdirectory, he will receive the same opportunities as "close friends". Rights - wx differ from the previous one, that "proxies" can write to this directory. They can copy the file to remove (unless, of course, know his exact name), etc. Again, an outsider can really write that file there, which you did not ask. Remove something there or rename, not knowing the names of files (and subdirectories), he will not be able.
And one more unusual case, which concerns the distribution rights for categories of users. The usual procedure for the appointment of different categories of rights on a file or directory:
- The owner - full rights (rwx);
- A group of trustees - the same, but without the right to change (r-x);
- All the rest - no rights (---).
Since the group are compiled byroot and ordinary users, as a rule, do not choose their neighbors in the group, then their files and directories have the same "tolerance" for the group and "everyone else". For example, for "unclassified" files (directories) - rwxr-xr-x, and for those that the owner wants
to protect rwx ------.
If you give access to "the rest", albeit limited, for a group of "very close" - on the contrary to remove (it will look something like this- rwx---r-x)?
Then the group assigned to the file, will turn from the group "very committed" to a group of "particularly disliked. That is, a "black list", in which you can add (of course, to do so can only root) all those who have no credibility. Note that the system, checking the rights a particular user in relation to the file, first checks - not whether he is owner, then - if he is not in the group, and only then assigns it to "all others". So, even if "all other" have access to the file, but user had the misfortune to fall into the appropriate group, access rights of groups will be applied to him.

2.4 Flags
Besides the already discussed the attributes (owner, group, permissions), there is another attribute, which limits the possible actions with the file - "set of flags." Incidentally, the default ls command does not show flags (and most "filemanager" - too). You need to put lo key for it to show them. With the flags you can disable to change the contents of the file, its name, or both.
Flags are more "potent tool" than permissions. They are the same for all users, not dividing them into categories.

Moreover, their action can not be ignored by owner of the file, and even root. The only difference between the owner and root from other users, that they can remove the flags from the file.
Flags are divided into two groups, "user" flags and "super". The difference is that "custom" can deliver and remove as root, and the owner of the file, and set / remove the "super" can only root. According to the purpose flags are divided into:
- append - allowed only to "add" the file (of course, the file must also have permission “w”). Without this flag, if the user of the respective category are allowed to write to a file, it can both add something to the content of the file, and" abated, "i.e., to erase part of the contents. When append flag is set, any user (even root) can only add something to the end of the file, but will not be able to change anything in the already existing contents.
If this flag is set on the directory, then you can create files in it (or copy all files from other directories), but you can not remove or change their names. Naturally, the files themselves has effect of the flag. - nounlink - file (or directory) can not be deleted or renamed, even if the rights established in the directory (where the file is located) so permitit. At the same time, this flag is not prohibited from changing the contents of the file (unless, of course, permissions permitting);
- Immutable or change - "nothing can”. I.e., the file (directory) can not be removed or renamed, or change the content. Again, if this flag is on the directory, the files (contained in it) feel no effect. I.e., you can not add or remove a file in a directory, but change the contents of the files themselves this flag is not banned.
As already mentioned, these three flags are exist in two varieties, ie, in fact, there were six: three "custom" - uappend, uunlink and uimmutable and three "super" - sappend, sunlink and simmutable. There are two "unpaired" flag. This flags:
- archived (zipped file) - a file "super", i.e. it can be set only by a root, and similar "user" does not exist;
- nodump - and it is "user" flag, it can be set not only by the root, but by the owner of the file.
These flags are checked only by a few specific programs. For example, the flag nodump tells the dump, that this file can not be preserved in the archive.

2.5 Rights of created file
The new file appears as a result of work of any program. At the same time, in UNIX, there are system functions that allow you to change the file owner, group and permissions. Naturally, the program that generates file may cause these functions and thus create a file with any attributes. However, most programs do not use these features, so you can say that "in most cases”, the attributes of created files still follow a few simple rules.

Owner
The owner of the file is determined by the "effective userlD" program, which creates it. This means that in most cases the owner of the file will be the user who created it (naturally, with some programs). If the program "suid", i.e., during the execution it has rights of the user who owns the program, respectively, all files generated by this program will belong to the host of program, rather than the user, who launched it.
By the way, even if the program uses the system function, which change the file's owner, they will work only if its "effective userlD " will be userlD root. It means, if it will run by root user or it is "suid" and its owner is root.
In other words, no matter what the program an ordinary user uses (unless, of course, they are not "suid"), he can create files, the owner of which will be the only one - he. A regular user can not "present" file to someone else.

Group
Group of created file in FreeBSD is defined slightly unusual. It is always "inherited" from the directory where the file is created. That is, the file will have the same group, which has a directory.
Note that the user that creates a file may not even be a member of this group. It is, of course, not very good in terms of system security. The fact is that if a user creates an executable file and then put a bit sgid on it, the file is in the performance gets the right of group to which the user is not included and may have access to such files, which in the normal situation it is not allowed to come near. "
However, on FreeBSD this situation is provided and the system simply will not allow the user to set sgid bit on the file, if the user is not a member of the group, which "attributed" to the file.
In other flavors of UNIX group of file usually assigned to one which is "primary" user group, that creates a file (i.e., that which is written in its budget). And for that group to be as in FreeBSD "inherited" from the directory, on the directory itself should be a bit sgid.
Access rights
The access rights that a "freshly baked" file will have defines the parameter umask. He asked - what access bits SHOULD NOT stand in the permissions.
If this parameter is zero, then all the created files will have the same rights of access for all categories and look like rw-rw-rw-. Directory (created, for example by the command mkdir) will have access rights rwxrwxrwx. The same permissions are obtained in executable files, which create different translators (they, of course, put the bits of "execution" the result of their work).
Parameter umask can view or edit with the same command umask. Umask command simply shows the current value of this parameter without any arguments. In order to change it, it is necessary for command to show as an argument the number that the system" deploy "in the appropriate bits.
If each group of three bits (which corresponds to a separate category of rights of access) be considered as a binary number, then "turning" them separately in decimal digits, we obtain the number of three digits, which reflects the value of all bits in the permissions. If you are not very familiar with the octal notation, you can just consider this number as three separate decimal numbers.
In FreeBSD the default command files that run at logon, all users, (including root) have an inserted command that sets the umask, equal to 022. It means, only bits of resolution record for the group and "all others" are canceled. If you are not satisfied, you can change the argument in the appropriate file (usually files.login or profile in the user's home directory) or change the parameter umask at any time "manually".

Changing the permissions during copying and moving files.

This question is actually more complicated than it might seem. The fact is that the answer on it depends on many conditions:
- Who copies (moves) files, root or normal user;
- What programs, and with what keys shall be used;
- Copy the file to an empty space or there already exists a file with that name.
Nevertheless, here are some general rules that define - what permissions may be caused as a result.
First, during copying (for example, with cp) a new file is creating. And during the move (for example, the command mv), only the location of the file is changing (and possibly the name).
Therefore, if the "average user" copies the file, the same rules as when you create the file are present. I.e., the owner of the copy becomes the user who created it, the group "inherited" from the directory and access rights themselves determined by the parameter umask.
Strictly speaking, if the copy performs by root, then these rules apply to him (i.e., the owner of the copy will be root, the group will be taken from the directory, and the rights of access will be establish in accordance with the umask). However, root can change the behavior of command cp. This command has the key (-p – to preserve permissions), which means that we should preserve all the attributes (owner, group and permissions) during copying.
Common user, even using the -p will not be able to preserve owner and group, but will get permissions same as in the original file. In addition, the suid and sgid bits are also "reset".
There is another situation when copying saved all the attributes of access. This happens when the "destination" file with that name already exists. Actually, in this case the file is not created, but its content is replaced. Therefore, even if this operation will go through a normal user (naturally, for this it is necessary that he is allowed to write to existing file), all attributes, including the owner and group will preserve. But the suid and sgid bits anyway will reset.

But when you move the file all attributes are stored (even "dangerous" bits of suid and sgid). However, do not forget that to an ordinary user could move someone else's file, it must have write permission in the directory where the file is transferred and the one from which he transferred (because there a record of the file should be deleted). Such situation in a normal system, as a rule, does not occur.

Changing of owner and group
First, it must be noted - who can change the owner and group for the file (directory).
Of course, root can make it.
Nobody can change the owner of the file, except the root.
But the group of a file can change the owner of the file itself, but only if he is a member of this (new) group.
To change the file's owner the command chown is used ("change owner"). You can use it to replace the group, but to change this attribute there is a special command chgrp ("change group").

Command chown
Chown command is very simple.

chown <new owner> <file name >
If you want to change not only the owner but the group, then:

chown <new owner>: < new group> <file name>

By the way, no one bothers to specify in the command the old owner, then only the group will change.
And, of course, if you want to replace the owner (group) on multiple files, instead of file name you can specify a suitable "template", such as "*" (to perform the operation for all files in the current directory). If you want a similar operation to be carried out not only in the current directory, but in all the "downstream" subdirectories, key-R (recursively) will help you.

For example, the command

chown -R bob:users *

will replace owner with bob, and the group with users, for all files and subdirectories in the current directory and "below", i.e., within subdirectories themselves.

Chgrp command
Chgrp command is very similar to the previous one, but as the first argument it needs to specify the name of the new group for the file (or files).
chgrp <new group> <file name>
All that was said about the command concerning the execution of chown over multiple files and key-R, also applies to the command chgrp.
Access rights (permissions)
Access rights, except the root can change also the owner of the file (directory). Incidentally, note that the host if the file may inadvertently install such bits of access, that he will not be able to use this file by appointment. But, no one would refuse him to correct their own mistakes.
So, to change the access rights (permissions) command chmod ("change mode") is used. In general, this command looks like the previous ones (that change the owner and group).
chmod <what to do> <file name>
But, unlike the previous commands, the second argument ("what to do") is more complicated. It can be divided into three parts:
- “Categories of users”;
- "Operation";
- "Access bits.

u (user) - owner

g (group) - group
o (other) - all other

a (all)- all three categories

-
+
=
r
w

x
s or t
First user category is set (owner, group, or "all others"). And, you can put multiple letters, denoting thus multiple categories. For example, go would mean that the rules change once and for group and for "all others". If you need to change the law immediately to the three categories, you can write three letters - ugo or just letter a (all three categories).
Then the "operation" (add right or vice versa - remove) is indicated. And finally, after the "operation" one or more bits of access that is necessary to change are indicated. The value of these bits of was considered in detail.

“Operation” probably requires some explanation. As you might guess, the sign "-" and "+" means "remove" or "put" the relevant law.
A sign "=" means both at the same time. The fact is that if you specify, such as a + x it will mean to add a bit of x to the category "other", but does not affect r and w bits for the same category. But pointing out the action as o = rx, you agree to tell the system “to set the bits of r and x, and remove the bits of w, if it was there ".
S bit has a different meaning (suid or sgid) depending on which part of the permissions it is. So if you want to put exactly suid bit, "what to do" should look like u + s, but if you need sgid, then- g + s. Sticky bit put command chmod a + t....
As you can see, the syntax of this command is quite flexible (but complicated). In addition, the second argument ("What to do") may consist of several "actions" listed by a comma.

For example, you can set the command chmod a = rx, u + w mydir,

this will mean - "for all categories of rights r-x, and for the owner also w (write permission)."
In addition, the command chmod (more precisely - its first argument) has another form.
Since all the bits of access - it is really binary bits of one cell, "advanced" user can specify the right number (in octal form), which should be obtained after the change of rights.
Octal representation is chosen because the translation in a binary number, each group of three bits "rolled" into one number. Thus, you simply have to specify three numbers, each of which describes a category of users (more precisely - the right for this category). For example, permissions rwxr-xr-x can be represented in octal form as 755. And, therefore, such rights may be displayed by a command
chmod 755 myfile
Regarding the implementation of this operation on multiple files or "recursive" bypass of all subdirectories, everything is the same as for the commands chown, chgrp. As the file name can be given "template", and to bypass all the subdirectories, the key –R is used.

Flags

The command that puts / removes the flags - chflags (“change flags “). The format of it is quite simple
chflags <flags> <file name>
Argument <flags> is the name of the flag or multiple flags separated by commas. The names of the flags described in the section on the flags. In addition, this command understands abbreviation words also.
sappend - sappnd
uappend - uappnd
sunlink - sunlnk
uunlink - uunlnk
simmutable - schange or schg
uimmutable - uchange or uchg
archived - arch
nodump not reduced
In order to remove the flag, you must specify its name with a prefix no-nosappnd, nosunlnk, noschg etc.
Exception is the flag nodump. In order to remove him it should be not nonodump but simply dump.
Naturally, as the previous command, chflags can be applied to multiple files and "recursively" to bypass subdirectory (the key is the same -R),

3 Control questions
1. What is a file?
2. What is directory?
3. Which structure file system UNIX has?
4. What rights of access exist in the files, what do they mean?
5. What rights of access exist in the directory, what do they mean?
6. What other bits of access do you know?
7. What is the flag? What flags do you know?
8. With the help of what command the permissions on the file, catalog can be changed?
9. With the help of what command the owner and group that owns the file can be changed?

4 Hometask
1. Examine the key provisions.
2. Write the answers to the control questions.
3. Prepare for the lab assignments.

5 Laboratory assignment
1. Make the following structure of directories and files.
Create a directory with a name as brigada-XX, where XX - number of brigade (provided by teacher). In this directory, create so much directories how many people in the group. Each of the directories should be named corresponding to the names of the brigade.
[brigada-XX]
|

|\
Ivanov
|\
Petrov

\

Sidorov

2. Look through a list of the contents of directory [brigade-XX]. Explain existing attributes of the directory.
3. Create three file in any directory. Explain the existing file attributes.
4. Move one of your files in the remaining two directories.
5. Change the secure of one of the files so, that no other category of users, except you, will not be able to read the contents of the file. Check the results.
6. Change the secure of file №2 so that only you or members of your group could read and write to a file, and everyone else could not do it.
7. Count the number of lines in the file №1.
8. Show all levels under your home directory on the screen.
6 Requirements for the content of the protocol
6.1 Name of laboratory work.
6.2 Purpose.
6.3 Results of the hometask.
6.4 Brief description of the work done.
6.5 Conclusions of the work done.
6.6 Date, signature of the student, visa of a teacher.

Дата добавления: 2015-11-14