9.3. Hantera behörigheter

Linux är definitivt ett fleranvändarsystem, så det är nödvändigt att tilhandahålla ett behörighetssystem för att kunna kontroller den mängd tillåtna åtgärder på filer och mappar, vilket omfattar att systemresurser och enheter (i ett Unix-system representeras en enhet av en fil eller mapp). Denna princip är vanlig för alla Unixsystem, men det är alltid nyttig med en påminnelse, speciellt då det finns några intressanta och relativt okända avancerade användarfall.

9.3.1. Owners and Permissions

Varje fil eller katalog har specifika rättigheter för de tre användarkategorierna:

dess ägare (symboliserad av u som “user”);
dess ägargrupp (symboliserad av g som i “group”), representerade alla medlemmar i gruppen;
övriga (symboliserad av o som i “other”).

Three basic types of rights can be combined:

läs (symboliserad av r som i “read”);
skrivning (eller ändring, symboliserat av w som i ”write”);
exekvera (symboliserad av x som i ”eXecute”).

Då det gäller filer är det lätt att förstå dessa rättigheter: läsåtkomst tilåter läsning av innehållet (inklusive kopiering), skrivrättighet tillåter att ändra den, och körrättighet tillåter dig att köra den (vilket endast fungerar om det är ett program).

SÄKERET setuid och setgid

Two particular rights are relevant to executable files: setuid and setgid (symbolized with the letter “s”). Note that we frequently speak of “bit”, since each of these Boolean values can be represented by a 0 or a 1. These two rights allow any user to execute the program with the rights of its owner or its group, respectively. This mechanism grants access to features requiring higher level permissions than those you would usually have.

Eftersom ett setuid-rootprogram systematiskt körs med superanvändarens identitet är det väldigt viktigt att försäkra sig om att det är säkert och pålitligt. En användare som skulle kunna få det att köra ett kommando av eget val skulle då kunna låtsas vara root-användare och få all rättigheter i systemet.

If you require running a program under a different user or if a program requires higher permissions, the sudo, su, or runuser commands are usually better choices than using these bits (see Avsnitt 8.9.4, ”Dela administratörsrättigheter”).

En katalog hanteras annorlunda. Läsrättigheter ger rätt visa listan av innehåll (filer och kataloger), skrivrättighet möjligör skapandet eller borttagandet av filer, och exekveringsrättighet ger möjlighet att passera genom den (speciellt för att gå där med kommando cd). Att kunna passera genom en katalog utan att kunna läsa den ger rättigheter till att komma åt poster däri som är kända till namn, men det går inte att finna dem om du inte vet om deras existens med deras exakta namn.

SÄKERHET setgid-katalog och sticky bit

setgid gäller också på kataloger. Varje nytt objekt i en sådan katalog kommer automatiskt tilldelas samma grupp som ägaren av den överordnade katalogen. Istället för att ärva skaparens huvudgrupp, som i vanliga fallet. Detta gör att användaren inte behöver ändra sin huvudgrupp (med kommandot newgrp) om hen arbetar med ett filträd delat mellan flera olika användare i samma tilldelade grupp.

”Sticky bit” (symboliserad av bokstaven ”t”) är en rättighet som endast är användbar i kataloger. Den är speciellt använd för tillfälliga kataloger där alla har skrivrättighet (som /tmp/): det begränsar borttagning av filer så att endast deras ägare (eller ägaren av överordnad katalog) kan göra det. Utan detta skulle alla kunna ta bort andra användares filer i /tmp/.

Tre kommandon kontrollerar rättigheterna associerad med en fil:

chown användare fil ändrar filens ägare;
chgrp grupp fil ändrar ägargrupp;
chmod rättigheter fil ändrar filens rättigheter.

Det finns två sätt att presentera rättigheter. Den symboliska representationen är nog den som är enklast att förstå och komma ihåg. Det innebär bokstavsymbolerna som tidigare nämnts. Du kan definiera rättigheter för varje kategori av användare (u/g/o), genom att ange dem explicit (med =), att lägga till med (+), eller dra ifrån med (-). Sålunda ger formeln u=rwx,g+rw,o-r ägaren läs-, skriv- och ekexveringsrättigheter, lägger till läs och skrivrättigheter för ägargruppen och tar bort läsrättigheter för andra användare. Rättigheter som inte ändras genom tillägg eller borttagning lämnas omodifierade. Bokstaven a, för “all” täcker alla tre katagorier av användare så att a=rx ger alla tre katogorerir samma rättigheter ( läsa och exekvera, men inte skriva).

Den oktala representationen associerar varje rättighet med ett värde: 4 för läsning, 2 för skrivning och 1 för körning. Vi associerar varje kombination av rättigheter med summan av siffrorna. Varje värde tilldelas sedan till olika kategorier av användare genom att lägga dem i ordning (ägare, grupp, övriga).

For instance, the chmod 754 file command will set the following rights: read, write and execute for the owner (since 7 = 4 + 2 + 1); read and execute for the group (since 5 = 4 + 1); read-only for others. The 0 (zero) means no rights; thus chmod 600 file allows for read/write rights for the owner, and no rights for anyone else. The most frequent right combinations are 755 for executable files and directories, and 644 for data files.

För att representera speciella rättigheter kan du som sätta ett fjärde tal som prefix, där bitarna för setuid, setgid och sticky är 4, 2 and 1. chmod 4754 kommer att associera biten för setuidmed tidigare beskrivna rättigheter.

Observera att användningen av oktala notation endast tillåter att ange alla rättigheter samtidigt på en fil; du kan inte använda den för att lägga till en ny rättighet, som läsrättighet för gruppägaren, eftersom du måste räkna med befintliga rättigheter och räkna ut nya motsvarande numeriska värden.

TIP rekursiv operation

Ibland måste vi ändra rättigheter för ett helt filträd. Alla kommandon ovan har flaggan R för att rekursivt kunna gå in i underkataloger.

The distinction between directories and files sometimes causes problems with recursive operations. That is why the “X” letter has been introduced in the symbolic representation of rights. It also represents the right to execute, but it applies differently to directories and files.

For directories it adds executable permissions to the chosen user(s). For files, it adds the executable bit only if at least one of the users (owner, group, or others) already has executable permissions. Let's demonstrate it, because this bit can be confusing:

$ ls test.txt
  -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt
  $ chmod u+X test.txt
  $ ls test.txt
  -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt
  $ chmod o+x test.txt
  $ ls test.txt
  -rw-r--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt
  $ chmod u+X test.txt
  $ ls test.txt
  -rwxr--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt

The example shows a typical file with its default permissions: its owner can read and write it, the owner's group and all other users can read it. The next operation (u+X) won't add executable permissions for the owner of the file, because permissions to execute have not been assigned. The operation has no effect on the file. Next we assign execute rights for "other" users and repeat the operation. This time it is successful, because at least one user group already had executable permissions.

It is a misconception that this bit will only affect directories. If files and directories have mixed permissions, it is often a good idea to use the find command to locate the targets you want to operate on.

YTTERLIGARE umask

When an application creates a file, it assigns indicative permissions, knowing that the system automatically removes certain rights, given by the command umask. Enter umask in a shell; you will see a mask such as 0022. This is simply an octal representation of the rights to be systematically removed. In this case, the write right for the group and other users: With the above umask value, the default for directories 777 becomes 755 and the default permissions for files 666 become 644.

The system's default value is handled by pam_umask(8) and /etc/login.defs.

If you give it a new octal value, the umask command modifies the mask. Used in a shell initialization file (for example, ~/.bashrc or ~/.profile), it will effectively change the default mask for your work sessions.

9.3.2. ACLs - Access Control Lists

Many filesystems, e.g. Btrfs, Ext3, Ext4, JFS, XFS, etc., support the use of Access Control Lists (ACLs). These extend the basic features of file ownership and permission, described in the previous section, and allow for a more fine-grained control of each (file) object. For example: A user wants to share a file with another user and that user should only be able to read the file, but not write or change it.

For some of the filesystems, the usage of ACLs is enabled by default (e.g. Btrfs, Ext3, Ext4). For other filesystems or older systems it must be enabled using the acl mount option - either in the mount command directly or in /etc/fstab. In the same way the usage of ACLs can be disabled by using the noacl mount option. For Ext* filesystems one can also use the tune2fs -o [no]acl /dev/device command to enable/disable the usage of ACLs by default. The default values for each filesystem can usually be found in their homonym manual pages in section 5 (filesystem(5)) or in mount(8).

After enabling ACLs, permissions can be set using the setfacl(1) command, while getfacl(1) allows one to retrieve the ACLs for a given object or path. These commands are part of the acl package. With setfacl one can also configure newly created files or directories to inherit permissions from the parent directory. It is important to note that ACLs are processed in their order and that an earlier entry that fits the situation has precedence over later entries.

If a file has ACLs set, the output of the ls -l command will show a plus-sign after the traditional permissions. When using ACLs, the chmod command behaves slightly different, and umask might be ignored. The extensive documentation, e.g. acl(5) contains more information.