Arch Linux

Verzeichnis-Berechtigungen unterscheiden sich

wtex

Guten Abend in die Runde,
beim heutigen Update habe ich folgende Warnmeldung erhalten

(102/153) Aktualisiert wird intel-ucode [--------------------------------------------] 100% Warnung: Verzeichnis-Berechtigungen unterscheiden sich für /boot/ Dateisystem: 700 Paket: 755

Muß ich mir jetzt Sorgen machen?
Wie kann ich das gerade biegen?
Der Rechner läuft auch nach einem Neustart ohne Probleme.

Besten Dank vorab für die Inputs.

tuxnix

wtex
Muß ich mir jetzt Sorgen machen?

Nein

Wie kann ich das gerade biegen?

# chmod 755 /boot

Begründung:
Der Hinweis ist lediglich eine Warnung.
Wenn das Verzeichnis /boot die Rechte 700 anstatt wie üblich 755 hat, dann bedeutet dies lediglich, dass du als normaler Benutzer nicht ins Verzeichnis schauen darfst. An den Dateirechten im Verzeichnis ändert sich dadurch nichts.
Du kannst vorher und hinterher mal ls -l /boot bzw.
# ls -l /boot ausprobieren.

Wenn /boot 755 Rechte hat sieht es dann so aus:

ls -l / |grep boot
drwxr-xr-x   4 root root  4096 14. Mai 16:44 boot
``

wtex

tuxnix
Danke für die schnelle Antwort.

Nach
# chmod 755 /boot
sieht das jetzt so aus bei mir:
ls -l /boot ls: Öffnen von Verzeichnis '/boot' nicht möglich: Keine Berechtigung
und
# ls -l /boot insgesamt 214624 drwx------ 5 root root 4096 20. Jän 2024 EFI -rwx------ 1 root root 134092935 15. Mai 17:53 initramfs-linux-fallback.img -rwx------ 1 root root 56930199 15. Mai 17:53 initramfs-linux.img -rwx------ 1 root root 13286400 12. Mai 19:56 intel-ucode.img drwx------ 3 root root 4096 15. Mai 21:28 loader -rwx------ 1 root root 15450624 15. Mai 17:53 vmlinuz-linux
Im Dolphin kann ich den Ordner boot nicht öffnen, nur als root.
So ganz denke ich stimmt das noch nicht?

tuxnix

wtex
Du musst dich neu anmelden bzw. rebooten, damit die neuen Rechte auch wirksam werden.

segfault

Ich glaube ja eher, dass es sich um den Mount der ESP handelt. Das Verzeichnis EFI deutet stark darauf hin. Alle Änderungen per chmod sind dadurch zum Scheitern verurteilt. Die ESP ist naturgemäß ein VFAT Dateisystem. Die Berechtigungen werden beim Mounten per /etc/fstab gesetzt/gesteuert.

Nebenbei finde ich 700 sicherer als 755.

tuxnix

segfault
Sorry, dass ich widersprechen muss.
Ich glaube du verwechselst gerade etwas.

Es gibt die VFAT formatierte Partition die mit BOOT gelabelt wird und als ESP dient. Um die geht es hier aber nicht. (Allerdings hast du Recht damit, dass es bei vfat keine Dateirechte gibt)

Es geht hier um die ROOT Partition auf der es das Verzeichnis
/boot gibt und um die Rechte dieses Verzeichnis.

segfault Nebenbei finde ich 700 sicherer als 755.

Bei Verzeichnisrechten regelt 'lesen' und 'ausführen' lediglich wer sich den Verzeichnisinhalt anzeigen lassen darf. Ich denke, dass vom bloßen Anschauen welche Dateien sich im Verzeichnis befinden keine Gefahr ausgeht. Wenn pacman darauf hinweist, dann sind die Arch Devs wohl auch dieser Meinung.

drcux

@tuxnix :

Ich glaube jetzt verwechselst du etwas: Das man sich neu anmelden muss, wenn man die Rechte im Dateisystem ändert, stimmt nicht. Sie sind sofort für alle aktiv.
Wenn er nach dem chmod 755 immer noch nicht in /boot schauen kann, liegt das Problem sehr wahrscheinlich in der fstab, wie segfault es schon vermutet hat. Auch alle Dateien habe ja 700, also stimmt scheinbar die Mountoption fmask=0022,dmask=0022 nicht.

wtex

Danke euch für die Inputs.
Ich kann hier jedoch keine Ungereimtheiten herauslesen.
Die Bootpartition kann ich nur als ROOT öffenen, irgendwas ist verbogen?

`cat /etc/fstab
UUID=efcaaa19-fc39-4c22-864e-43b365afbb35 / ext4 rw,relatime,errors=remount-ro 0 1

UUID=F7A0-3BC5 /boot vfat nofail,umask=0077 0 1

UUID=13fb001b-5e8e-44fd-bccd-fa09a86bbeff /home ext4 defaults 0 2

UUID=8c033e66-a418-4951-90d1-9d73b688d695 /home/innfra/HDD ext4 defaults 0 2
`

sudo lsblk -o name,uuid,fstype,mountpoint NAME UUID FSTYPE MOUNTPOINT sda ├─sda1 F7A0-3BC5 vfat /boot ├─sda2 efcaaa19-fc39-4c22-864e-43b365afbb35 ext4 / └─sda3 13fb001b-5e8e-44fd-bccd-fa09a86bbeff ext4 /home sdb ├─sdb4 └─sdb5 8c033e66-a418-4951-90d1-9d73b688d695 ext4 /home/innfra/HDD sr0

drcux

wtex umask=0077

Da ist doch der Schlingel, umask=0022 in der fstab sollte passen.

Gerry_Ghetto

Ein Blick in die Ausgabe von mount würde wohl am meisten Informationen liefern. Oder mount | grep boot.

wtex

mount | grep boot /dev/sda1 on /boot type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

wtex

drcux
ich hab jetzt die fstab auf umask=0022 geändert.
Probiere mal einen Neustart.

wtex

Das wars wohl.
Bekomme beim Update von intel-ucode die oben beschriebene Fehlermeldung nicht mehr.
Kann auch Boot wieder als normaler User öffnen.

Besten Dank an alle.