12.1 (Conspect) Permissions

I owe it to you last time to make it clear that we're writing a program with C:

   1 #include <unistd.h>
   2 #include <stdio.h>
   3 
   4 int main() {
   5   int i;
   6   pid_t p;
   7 
   8   p = fork();
   9   for(i=0; i<100; i++)
  10     printf("%d %s\n", p, p ? "parent":"child");
  11 
  12   pause();
  13 }

You can see in the terminal when compiling: '?' - thornary operation in C.

In other architectures where the scheduler works a little bit differently, this leads to forkmes. The scheduler is different, or maybe the system outputs in a different order in which one process outputs and the second process outputs, that is, the output of multiple processes.

Permissions

Each user has a unique identifier that lies in the directory - it corresponds to the login name under which we registered. User passwords are not stored anywhere at all. If no vulnerability is found, the password simply cannot be recovered. It is possible to find a hash that matches (hash collision) - it means that two different input data blocks and for hash functions such that collisions exist for most hash functions, but for "good" hash functions the frequency of their occurrence is close to the theoretical minimum.

However, if you try hard - it is possible to attack the dictionary because most users are not very smart in creating a password - so the field with passwords was removed in another file and now it is not there. All we have is an indicator, group number, home directory, and shell.

Each user has an ID and each process has -ef also has an indicator (digits) - it also has an owner - the processes belong to some user. A part of the system processes belongs to the user. Some belong to a special user. When we do for the entire process environment is inherited - the process owner is also inherited .

In this way we can imagine some reasons for stealing data of different users. Because we see that each process file belongs to some user and on the basis of what the user wants to do - process data of user A with data of user B - we decide what to do with this file - this law is called 'subject-object model of access rights'. Subject - userID All system processes and files belong to this or that user, and we can decide what that user can and cannot do.

There are only three species RWX (so-called attributes) or What can a user do with his file:

• Let's create a file we can look at its contents
• It's readable and writable.
• The process itself and the owner can do with the file.

The first triplet determines that the process we run will belong to us on this basis the system primacy decision that the process we run that can do the file If we say we add something to this file.

!? Let's lock ourselves out of this:

chmod u-w o file

You got it . And all of a sudden, we can't fit any more into it. Instead of writing it to a file, the system gives us an error that it is forbidden because the ID matches the ID of someone who works with it then we can make it again for writing. And now this team is doing a great job.

!? We can disable reading from this:

chmod u-r o file

Writing works and reading doesn't. The fact that we are forbidden to read from this file both file ID and user ID - will match - we use the first tremor, which shows that writing can't be read. Let's return as it was and everything can be done again.

A slightly stranger but completely logical behavior of a file if it is available for execution:For example, there is a script.

cat > script
Echo "QQ"

Echo "QKRQ"

^D - complete input

However, we can create a simple QQ print program - We can run it.

What happens if we chmod u+x script What will happen? - It's just being done. What does he know? Isn't that a test file? Shell defaults to a text file.

Script in Linux is an executable text file . The executor of the test file is shell. If the system is looking at the file and does not know what the file is, it runs the shell Program script - records a session in the terminal

It follows that we can specify who is the performer of our script. Because a program of what type doesn't know - an extension doesn't mean anything in Linux except a text editor and a compiler of the 'cc' type can slip - in all the other cases '.py' or something else - it doesn't affect anything.

In order for the interpreter pointer that will interpret our program to be inserted meaningful comments

• SUBAN #!/user/bin/python3 print("QQ") - will run the interpreter for this file because by default there is a shell and must be python3.

We can write our own interpreter as a sauce and specify scripts for it.

Back to the access pairs: We were just talking about access rights for the first three beeches - a triplet meanwhile there are two more. One answer is obvious if there is a master and there is no master and we can define access rights for the non-host. If we try to gain access to it in another way, then that was not us. There's nothing we can do about it. This is a rather dumb system of access rights organization that is flexible when introducing a multiple subject of the system or a group. A file/process can belong to a user but it can still belong to a certain group. The user can be a member of several groups. Multiple subject/group - there can be a collection of participants, a group can have many participants each user can be a member of several groups . When several but not all system users (members of a certain group) get access to this group at once - the third triplet is involved. In reality, the situation is a bit more complicated. In this list I specify which user and which group he belongs to.

Multiple subject 0 - if the process belongs to a user of a multiple group who is the owner of this file - 1 triplet

If 2 triplets, the user is in a group And if an extraneous triplet 3 trembles...

Discretionary rights - the rights of the subject-subject end there. As far as all the processes generated from this process

A slightly more tricky catalogue situation

We won't be able to use the file name to get to its contents. Read access write access to the directory - the right to change the list of files in this directory. Write access to the directory is not related to the fact who the file belongs to.

root, or superuser

is a special account and group of users in UNIX-like systems with an identifier, the owner of which has the right to perform all operations without exception. The superuser of UNIX-like systems has a login "root" only by default and is easily renamed if necessary.

Someone else's file in our directory -f says rm don't ask, delete, i.e. remember what a file name is, it's another link to the anode. Like the monster said, I'm not gonna eat you. $HOME - your indirect catalogue /tmp - anybody here can write down files.

Because /tmp is generally available for all users to read and use. Multi-access directories have 10 bits - now this is for directories and the t bit means that other people's files cannot be deleted from this directory. The mechanics of violation - any process in the system as if tells us : ' I want to be different, user, plise start my process with the name of another user' . The point is that in Linux there is a trusted subject the only special user whose ID guarantees access rights - root with 0 I can start the process:

• Suppose we wanted to start a process that needs exclusive ping rights because the utility generates a low-level network layer packet of two IPs

A normal user is not allowed to do this.