/bin/sudo must be owned by uid 0 and have the setuid bit set

[RAID10]

Moin zusammen,
ich habe wohl mist gebaut und kann nun keine Pakete mehr installieren oder per sudo etwas ausführen.
Hintergrund ist, das ich den composer und laravel per ssh installiert habe.
Das läuft zwar nun alles, aber eines der Terminal-Befehle ist wohl nach hinten losgegangen.
Einloggen kann ich mich per SSH, sobald ich nun per SSH sudo eingebe kommt:
"pkexec chmod a=rx,u+ws /usr/bin/sudo"

Hat jemand hier einen Ansatz für mich.


Gruß
André

 

[luddi]

Also zum Verständnis... Gbist du nur sudo ein wie ich annehmen kann gefolgt von einem Befehl.

 

[RAID10]

Moin Luddi,
ja.
Hatte gestern die Standard-PHP Version angepasst (auf 7.2).
Heute wollte ich auf 7.3 gehen:
"sudo cp /volume1/@appstore/PHP7.3/usr/local/bin/php73 /bin/php"

Daruf kommt nun:
sudo: /bin/sudo must be owned by uid 0 and have the setuid bit set

Und auch im Packet-Manager lässt sich nun kein Paket mehr installieren.

Sorry für meine bescheidenen Linux Kentnisse

Gruß
André

 

[luddi]

Such doch mal im Internet danach... Da gibt es einige Treffer. Vielleicht ist da ein Workaround dabei.

z.B. hier (schau dir die 2. Antwort an):
https://stackoverflow.com/questions...-0-and-have-the-setuid-bit-set-version-ubantu
Was bitte hast du vorher getan dass das passiert ist?

 

[RAID10]

Moin,
ich bin nach dieser Anleitung vorgegangen:
https://tech.setepontos.com/2017/05/21/installing-php-composer-on-a-synology-nas/
Ich vermute das es irgendwo hier passiert sein muss:

• You’ll need to fix your project folder’s permissions (this is a simple consideration for a development server, not production – check this). Note that in a Synology DSM you need to consider http instead of www-data:

sudo chown -R :http .
sudo chmod -R g+r .
sudo chmod -R g+rw public/.

 

[luddi]

SSH your NAS, and issue the install commands (note: change folder accordingly to where you want to install it; example below will be in current directory)

Mich würde nun interessieren auf welchem Verzeichnis du dich auf der Konsole befunden hast als du die Befehle ausgeführt hast.

Denn hier hast du die Befehle relativ zum gewählten Pfad ausgeführt. Es wäre besser wenn man statt . oder public/. die Absoluten Pfade angegibt. Somit stellt man sicher dass man die Rechte nicht auf Falscher Ebene vergibt.

 

[RAID10]

Mich würde nun interessieren auf welchem Verzeichnis du dich auf der Konsole befunden hast als du die Befehle ausgeführt hast.

Das kann ich nicht mehr nachvollziehen.

Folgendes hatte ich nochmal getestet:
Befehhl: ls -l /usr/bin/sudo
Ergebniss: -rwxr-xr-x 1 root http 126056 May 12 00:10 /usr/bin/sudo

Kann man damit was anfangen?
Was könnte ich noch tun?

Gruß
André

 

[luddi]

z.B. hier (schau dir die 2. Antwort an):

Hast du dir das bereits einmal durchgelesen? Oder überhaupt selbst einmal nach "/bin/sudo must be owned by uid 0 and have the setuid bit set" im Internet gesucht?

 

[Tommes]

Hi!

Also eigentlich bin ich für dieses Problem der falsche Ansprechpartner, da ich weder weiß, wie du das geschafft hast, geschweige denn, wie du das wieder grade rückst. Jedoch hat mich das Thema interessiert und eine kurze Suche hat mir dann das ausgespuckt *klick* Ob sich das so auf die DS übertragen lässt und welche Seiteneffekte das ausführen der Befehle noch haben könnte, kann ich nicht beantworten... aber vielleicht hilft es ja.

Tommes

 

[RAID10]

Moin Tommes,
das lässt sich so leider nicht übertragen, da ich nicht auf root wechseln kann $su
Sobald ich das versiche kommt eine Passwortabfrage und das Admin Passwort funktioniert hier nicht.

Den Befehl:

# pkexec chmod a=rx,u+ws /usr/bin/Sudo

Habe ich dann in der der DSM Oberfläche als Task (Systemsteuerung -> Aufgabenplannung) angelegt und als root ausführen lassen- scheinbar ohne Erfolg.

 

[tproko]

Wenn sonst nichts hilft probier mal den einfachen DSM Reset wo Admin und Netzwerk rückgesetzt wird.

In deinem Fall fürchte ich aber, hilft nur mehr DSM neuaufsetzen.