Bullseye: Permission denied mit sudo

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Bei Ausführung eines Pythonprogramms in Bullseye mit sudo kommt ein

    PermissionError: [Errno 13] Permission denied:

    In Buster und früheren Dist trat dieser Effekt nicht auf:

    ERROR:root:Ein Fehler ist aufgetreten!
    Traceback (most recent call last):
    File "/home/kamera/aufnahme.py", line 429, in
    breitbild.save(verz + bearbeitet)
    File "/usr/local/lib/python3.9/dist-packages/PIL/Image.py", line 2428, in save
    fp = builtins.open(filename, "w+b")
    PermissionError: [Errno 13] Permission denied: '/mnt/ramdisk/test1.jpg'

    und:

    ls -al /mnt/ramdisk/test1.jpg 

    -rw-r--r-- 1 kamera kamera 571868 15. Feb 12:10 /mnt/ramdisk/test1.jpg 

    Das Programm aufnahme.py wird u. a. aus einem php-Script gestartet, deswegen root weil in sudoers eingetragen.

    Hat irgendjemand eine Erklärung bzw. Lösung dafür, wäre sehr dankbar nach stundenlangem probieren. <3

  • Wer führt was aus und wem gehört was? Wie ist /mnt/ramdisk gemountet? Usw....

    Das Programm aufnahme.py wird u. a. aus einem php-Script gestartet, deswegen root weil in sudoers eingetragen.

    Muss das root ausführen? Und wenn ja warum?

    Bitte gib Infos, denn mit diesen paar Bröckchen kann keiner etwas anfangen, bzw. wäre es reiner Zufall, wenn jemand einen Treffer landen sollte.

  • Vielen Dank für Eure Antworten.

    Mein Programm aufnahme.py lief bisher von Wheezy bis Buster mit denselben Einstellungen. Daher hat es mich eben gewundert, daß es mit Bullseye aufeinmal nicht mehr ging.

    Ich werde mich jetzt doch noch mal eingehend mit den Benutzerrechten befassen.

  • Nach zahlreichen erfolglosen Versuchen melde ich mich jetzt noch einmal.

    Das Problem ist wie oben erwähnt, daß ich mit root nicht auf Dateien des Benutzers kamera zugreifen kann.

    Dazu noch einige erläuternde Angaben:

    Raspbian Bullseye

    Linux kam32bit 5.15.84-v7l+ #1613 SMP Thu Jan 5 12:01:26 GMT 2023 armv7l

    Oben tauchte auch die Frage auf, wie ich die ramdisk gemountet habe: in fstab:

    tmpfs /mnt/ramdisk tmpfs nodev,nosuid,noexec,nodiratime,size=100M 0 0

    Der Eintrag in /etc/group:

    sudo:x:27:kamera

    Das Verzeichnis /mnt/ramdisk:

    kamera@kam32bit:~ $ ls -al /mnt/ramdisk

    insgesamt 236

    drwxrwxrwt 2 root root 200 7. Mär 18:47 .

    drwxr-xr-x 3 root root 3488 3. Feb 19:41 ..

    -rw-rw-r-- 1 kamera kamera 8 7. Mär 18:45 aktuell.txt

    -rw-r--r-- 1 kamera kamera 1239 7. Mär 12:05 aufnahme.log

    -rw-r--r-- 1 kamera kamera 54 7. Mär 00:23 loeschen_lokal.log

    -rw-rw-r-- 1 kamera kamera 159 7. Mär 00:21 sonn_ber.log

    -rw-rw-r-- 1 kamera kamera 213020 7. Mär 18:48 test1.jpg

    -rw-rw-r-- 1 kamera kamera 2205 7. Mär 18:45 test1-th.jpg

    -rw-rw-r-- 1 kamera kamera 0 4. Mär 21:14 test.jpg

    -rw-rw-r-- 1 kamera kamera 0 4. Mär 21:14 verschlusszeit.log

    Wenn ich z. B. diese Datei bearbeiten will:

    sudo nano /mnt/ramdisk/aktuell.txt

    kommt beim Speichern:

    [ Fehler beim Schreiben von /mnt/ramdisk/aktuell.txt: Keine Berechtigung ]
    also derselbe Fehler wie oben beim Ausführen von aufnahme.py

    Muss das root ausführen? Und wenn ja warum?

    Nun, ich hab das so aus dem Internet nachvollzogen und es hat ja auch bisher funktioniert.

    Ich habe die Einträge in /etc/group verglichen mit denen in einem Buster-Image, sie sind indentisch!

    Wo könnte da noch ein Fehler sein, bitte um Hilfe!

  • Das Programm aufnahme.py wird u. a. aus einem php-Script gestartet, deswegen root weil in sudoers eingetragen.

    Hat irgendjemand eine Erklärung bzw. Lösung dafür, wäre sehr dankbar nach stundenlangem probieren. <3

    Ein php-Script wird, wenn nicht alles schon verkonfiguriert wurde, von www-data:http://www.data aufgerufen.

    Was hast Du wie, in sudoers eingetragen, und hast Du dabei sudoedit (fehlerfrei) verwendet ?

    Ist der User, der das fehlerhafte Script aufruft, in die Gruppe 27(sudo) aufgenommen ?

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Die sudoers habe ich mit visudo bearbeitet und sieht so aus:

    www-data ALL = (root) NOPASSWD : /home/kamera/video.py, /var/www/gpio.php, /home/kamera/aufnahme.py, /var/www/websudoscript.sh

    Das Problem ist allerdings schon grundlegender, weil wie in #1 zu sehen, die aufnahme.py mit root-Rechten ausgeführt wird:

    ERROR:root:Ein Fehler ist aufgetreten!

    Und wie in #5 berichtet, kann ich mit sudo keine Dateien vom User kamera bearbeiten!

    Ich werde jetzt das Bulleye-Image neu installieren und dann schaun mir mal ;)

    Danke an alle für Euer Mitdenken!

  • Fast nicht erkennbar:

    kamera@kam32bit:~ $ ls -al /mnt/ramdisk

    insgesamt 236

    drwxrwxrwt 2 root root 200 7. Mär 18:47 .

    drwxr-xr-x 3 root root 3488 3. Feb 19:41 ..

    -rw-rw-r-- 1 kamera kamera 8 7. Mär 18:45 aktuell.txt

    ....

    Es ist imho das "t" - Sticky Bit - im Verzeichnis /mnt/ zusammen mit dem chmod 777 Hoax.

    Wie kommt jemand auf die Idee das /mnt Verzeichnis mit chmod 1777 zu verhunzen, und was hat sich der Autor der Anleitung dabei gedacht ?

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Da muss ich den TO aber jetzt auch in Schutz nehmen. Er hat nie bewusst chmod 1777 gesetzt. Das macht das tmpfs, das er in die fstab eingetragen hat.

    Aus #5

    "Oben tauchte auch die Frage auf, wie ich die ramdisk gemountet habe: in fstab:

    tmpfs /mnt/ramdisk tmpfs nodev,nosuid,noexec,nodiratime,size=100M 0 0"

    Hier wird offensichtlich das Verzeichnis /mnt/ramdisk per default mit 1777 erstellt

    Die Ergänzung des fstab Eintrages auf

    tmpfs /mnt/ramdisk tmpfs nodev,nosuid,noexec,nodiratime,size=100M,mode=0777 0 0

    könnte das vom TO gewünschte Ergebnis bringen.

    /tmp und virtuelle /tmp Verzeichnisse haben ihre eigenen Regeln (deshalb auch das Sticky Bit).

    Servus !


    Edit: Es könnte auch mode=777 statt 0777 richtig sein

    < mount | grep tmp > zeigt die tmpfs an.

    RTFM = Read The Factory Manual, oder so

    2 Mal editiert, zuletzt von RTFM (10. März 2023 um 07:26)

  • Edit: Es könnte auch mode=777 statt 0777 richtig sein

    Vielen, vielen Dank, das war die Lösung. Da muß sich in Bullseye was geändert haben, weil wie schon erwähnt, es in den vorherigen Dists auch ohne mode... bisher funktioniert hat.

    Allen anderen, die sich wenigstens Gedanken gemacht haben, auch einen schönen Dank für die Hilfsbereitschaft. Als nicht so Linux-fiter ist man auf die Hilfe anderer angewiesen, sonst geht gar nichts!

    Einmal editiert, zuletzt von kamera-d (11. März 2023 um 10:26)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!