ubuntuusers.de

Guten Morgen,

ich habe ein Problem mit den Zugriffsrechten meiner /tmp-Partiton. Ich habe seit 1-2 Jahren eine recht restriktive Konfiguartion meine Gesamtsystems, hatte bisher allerdings noch nie Probleme damit.

Bei erstellen eines verschlüsselten Containers mit Veracrypt trat den gestern der folgende Fehler auf. Da die /tmp Partition etwa 17 GB groß ist, kann es an der Größe nicht liegen.

Also hab ich mir die Zugriffsrechte angesehen.

sudo ls -ld /tmp 
drwxrwxrwt 23 root root 4096 Apr  4 08:41 /tmp

sudo ls -ld /tmp/user
drwx--x--x 5 root root 4096 Apr  4 08:35 /tmp/user

Ist das Sticky-bit fürs /tmp Verzeichnis "üblich"?

Wenn ich den Besitzer des Ordners /tmp/user/ manuell ändere funktioniert alles reibungslos.

sudo chown -R benutzer:benutzer /tmp/user/

Allerdings wird der Besitzer nach jedem Reboot wieder auf root root zurückgesetzt. Wie lassen sich die Rechte denn für das /tmp Verzeichnis dauerhaft anpassen? Damit dort auch group lesen/schreibrechte bekommt?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

  GNU nano 4.8                      /etc/fstab                                  
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda5 during installation
UUID=2bcde232-0005-4d5d-8d22-6c70f34f772b /               ext4    errors=remoun>
# /boot/efi was on /dev/sda1 during installation
UUID=E427-E30A  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw           >
shmfs        /dev/shm         tmpfs   nodev,nosuid,noexec        0 0
proc    /proc        proc        defaults,hidepid=2    0 0
/dev/sda7       /home     ext4    nodev,nosuid    0 0
/dev/sda6       /var     ext4      defaults    0 0
/dev/sda8       /tmp     ext4    defaults,noexec,nosuid    0 0
/tmp           /var/tmp  none    defaults,noexec,nosuid,bind            0 0

Grüße

Hallo!

roosevelt schrieb:

Ist das Sticky-bit fürs /tmp Verzeichnis "üblich"?

Ja. Genau wie die Rechte der dort angelegten Ordner den Benutzer als Eigentümer definieren, soll nur dieser die Daten manipulieren können. Es ist theoretisch möglich über mount-Optionen oder die umask Benutzer und Gruppe, bzw. Rechte zu ändern, da würde ich aber von abraten, da es dir ja nur um das eine Verzeichnis geht.

Das einfachste wäre, dir eine systemd unit zu schreiben, die beim Hochfahren und nach dem mount ausgeführt wird und explizit die Rechte dieses Verzeichnisses ändert, wenn es persistent ist, insofern das Verzeichnis erstellende Programm keine Optionen dafür bietet. Mit VeraCrypt habe ich durch die unfreie Lizenz allerdings noch nie was gemacht, daher kenne ich die Konfigurationsmöglichkeiten nicht.

Hallo roosevelt,

tmp           /var/tmp  none    defaults,noexec,nosuid,bind            0 0

ohne Dateisystem ?

Gruss Lidux

Lidux schrieb:

ohne Dateisystem ?

Ist dann auch ein mem oder tempfs.

Lidux schrieb:

… ohne Dateisystem ?

Auch den Kontext lesen. 😛 (Das findet sich in der Zeile darüber.)

roosevelt schrieb:

Bei erstellen eines verschlüsselten Containers mit Veracrypt trat den gestern der folgende Fehler auf.

Der folgende? Ich habe da wohl etwas überlesen, denn davon finde ich nichts.

PS: (Naja, denken kann ich mir etwas.) Wie wird das Verzeichnis /tmp/user denn erstellt? Wird /tmp richtig geleert oder bleibt etwas erhalten?

1
2
3
4
5
6

fleet@MATE-focal ~ $ ls -ld /tmp/
drwxrwxrwt 17 root root 4096 Apr  4 18:32 /tmp/
fleet@MATE-focal ~ $ mkdir /tmp/tralala
fleet@MATE-focal ~ $ ls -ld /tmp/tralala
drwxrwx--- 2 fleet fleet 4096 Apr  4 18:32 /tmp/tralala
fleet@MATE-focal ~ $ 

Vielen Dank für eure Antworten.

ChickenLipsRfun2eat schrieb:

Es ist theoretisch möglich über mount-Optionen oder die umask Benutzer und Gruppe, bzw. Rechte zu ändern, da würde ich aber von abraten, da es dir ja nur um das eine Verzeichnis geht.

Korrekt, es geht mir eigentlich nur um das eine Verzeichnis, welches von Veracrypt verwendet wird.

Das Problem wird wohl vom Paket libpam-tmpdir verursacht, bzw. blockiert zu werden.

Da ich das Paket eher ungern entfernen möchte, hört sich der workaround mit der systemd unit vielversprechend an.

Für ein Beispiel, wie man die Rechte für ein Verzeichnis ändert, wäre ich sehr dankbar.

Du musst nach dem Anlegen des Verzeichnisses die gewünschten Berechtigungen setzen. Ich nehme an, das es für VeraScript schon eine Unit gibt, die startet (mount unit oder service unit)? Die kannst du dann als required definieren und entsprechend mit chown oder chmod die Berechtigungen ändern. Falls VeraCrypt auch ein vorhandenes Verzeichnis verwenden kann, kannst du es auch nach dem Einhängen von /tmp selbst anlegen. Das musst du ausprobieren, bzw. an die Situation anpassen.

Eventuell ist auch root generell falsch und der Container sollte dem Benutzer gehören, dann wäre eventuell eine user unit zum mount das richtige? Ich kann da nur raten — oder du führst konkreter an, was genau passiert und was passieren soll und ob sich das mit VeraCrypt so umsetzen lässt. Den letzten Teil können wohl andere besser beurteilen, die das auch benutzen/benutzt haben.

fleet_street schrieb:

… Wie wird das Verzeichnis /tmp/user denn erstellt? Wird /tmp richtig geleert oder bleibt etwas erhalten?

Auf die Fragen wurde bisher nicht eingegangen. Ich helfe mal nach:

man 5 tmpfiles.d
man 8 systemd-tmpfiles

systemd-tmpfiles  --cat-config | grep " /tmp/"