als root: su nobody = permission denied
Hallo Liste, ich habe vor kurzem festgestellt dass mein typo3 das ImageMagick nicht finden mag. Nach einigen Tests hab ich dann festgestellt, dass es wohl nicht an apache/php liegen kann, da ich selbst ohne php-safemode (execdir, opendir, etc) und mit allen datei rechten zware textfiles wunderbar auslesen kann, aber z.B. ein exec("ls") nie funktionieren will und immer mit dem linux error-code 127 beendet wird. (nein, an den pfaden liegt es auch nicht) So weit ich herausgefunden haben bedeutet 127 schlicht "file not found". 126 hätte ich noch irgendwie verstehen können, aber 127 war mir völlig schleierhaft. Das ganze testete ich danach, indem ich mich via root@ssh mit "su wwwrun" als selbiger anmelden wollte, bekam daraufhin aber plötzlich ein "su: /bin/false: Permission denied". Das gleiche auch für alle anderen (auch real) user accounts, die ich probiert habe. Die anderen Dienste laufen ohne erkennbare Probleme (postfix, smb shares, nfs). Nur Programme dürfen wohl von nicht-root usern nicht ausgeführt werden (ihre eigene shell eingeschlossen). Bin für jeden Hinweis dankbar. Viele Grüße aus NS Maik
M. Bader schrieb:
Das ganze testete ich danach, indem ich mich via root@ssh mit "su wwwrun" als selbiger anmelden wollte, bekam daraufhin aber plötzlich ein "su: /bin/false: Permission denied". Das gleiche auch für alle anderen (auch real) user accounts, die ich probiert habe.
Mit "cat /etc/passwd" siehst du in der letzen Spalte, wer sich wo/wie anmelden darf. steht dort /bin/false, darf sich der User nicht anmelden. /bin/bash ist die Standard-Shell, die normalerweise auch über /bin/sh erreichbar ist. Sollte dort wirklich /bin/bash oder /bin/sh stehen, ist dein System etwas (genauer: etwas mehr) kaputt. In diesem Fall: Schick mal die Ausgabe von "ls /bin/{ba,}sh -l"
From: Martin Ereth
Sollte dort wirklich /bin/bash oder /bin/sh stehen, ist dein System etwas (genauer: etwas mehr) kaputt. In diesem Fall: Schick mal die Ausgabe von "ls /bin/{ba,}sh -l"
Autsch, genau das wars. Ich hatte hatte wohl in einem *spät-nach-mitternächtlichen* Sicherheitswahn alle Files in /bin auf 700 root:root gesetzt. Nun alles wieder auf a+rx und es läuft. Vielen Dank Maik [denkt euch hier eines dieser smileys das mit dem kopf gegen die Wand hämmert] PS: Gibt es eigentlich files in /bin oder /usr/bin die man besser nicht auf a+rx stellen sollte? Doch eher nicht oder?
Hallo Maik, hallo Leute, Am Montag, 20. März 2006 17:34 schrieb M. Bader: [...]
Ich hatte hatte wohl in einem *spät-nach-mitternächtlichen* Sicherheitswahn alle Files in /bin auf 700 root:root gesetzt. Nun alles wieder auf a+rx und es läuft.
rpm --setperms -a wäre wohl die geschicktere Lösung ;-) (gefolgt von SuSEconfig, um /etc/permissions.* auch mit ins Boot zu bekommen)
[denkt euch hier eines dieser smileys das mit dem kopf gegen die Wand hämmert]
*LoL*
PS: Gibt es eigentlich files in /bin oder /usr/bin die man besser nicht auf a+rx stellen sollte? Doch eher nicht oder?
in /bin/: # ls -l /bin/ |grep -v "rwxr-xr-x\|^l" | sort # (SUSE 10.0) -rwsr-x--- 1 root audio 19700 2005-09-09 18:10 eject* (bei mir) das einzige Programm in /bin ohne Ausführrechte für alle -rwsr-xr-x 1 root root 108292 2005-09-13 15:03 mount* -rwsr-xr-x 1 root root 27648 2006-01-31 17:28 su* -rwsr-xr-x 1 root root 35636 2005-09-09 18:04 ping6* -rwsr-xr-x 1 root root 36028 2005-09-13 15:03 umount* -rwsr-xr-x 1 root root 36044 2005-09-09 18:04 ping* Diverse suid-root-Programme -r-xr-xr-x 1 root root 107652 2005-09-09 18:06 ps* -r-xr-xr-x 1 root root 27272 2005-10-25 15:34 login* -r-xr-xr-x 1 root root 7816 2005-09-09 18:05 mktemp* -r-xr-xr-x 2 root root 6432 2005-09-09 18:26 nisdomainname* -r-xr-xr-x 2 root root 6432 2005-09-09 18:26 ypdomainname* Denen fehlt nur (komischerweise) das Schreibrecht für den Owner. Frag nicht warum - ich habe aber vorsorglich einen Bugreport diesbezüglich eingereicht ;-) [1] Gleiches Spielchen für /usr/bin/: # ls -l /usr/bin/ |grep -v "r.xr-xr-x\|^l" | sort insgesamt 198344 -rw-r--r-- 1 root root 172984 2005-09-13 04:14 vlevel-bin -rw-r--r-- 1 root root 186 2005-09-13 03:35 pygtk-demo Überhaupt nicht ausführbar? Dann ab zu [2] -rwsr-x--- 1 root trusted 33440 2005-09-09 18:30 crontab* -rwsr-x--- 1 root trusted 41796 2005-09-09 20:46 at* Da sind zwei ohne Rechte für alle und noch dazu suid-root. -rwsr-xr-x 1 lp sys 10512 2005-09-12 23:08 lppasswd* -rwsr-xr-x 1 root root 111368 2005-09-09 20:44 sudo* -rwsr-xr-x 1 root root 13252 2005-09-09 18:28 rlogin* -rwsr-xr-x 1 root root 15668 2005-10-25 15:34 newgrp* -rwsr-xr-x 1 root root 18792 2005-09-09 18:28 rcp* -rwsr-xr-x 1 root root 832328 2006-02-15 15:19 gpg* -rwsr-xr-x 1 root root 9604 2005-09-09 18:28 rsh* -rwsr-xr-x 1 root shadow 13756 2005-10-25 15:34 expiry* -rwsr-xr-x 1 root shadow 71984 2005-10-25 15:34 chsh* -rwsr-xr-x 1 root shadow 75144 2005-10-25 15:34 passwd* -rwsr-xr-x 1 root shadow 76052 2005-10-25 15:34 chfn* -rwsr-xr-x 1 root shadow 77660 2005-10-25 15:34 gpasswd* -rwsr-xr-x 1 root shadow 78132 2005-10-25 15:34 chage* -rwsr-xr-x 2 root root 5493 2005-09-13 01:58 man* -rwsr-xr-x 2 root root 5493 2005-09-13 01:58 mandb* Wieder diverse suid-root. -rwxr--r-- 1 root root 5592 2005-12-17 15:51 wttyhx* Komische Berechtigung ;-) - ist aber in 10.1 beta8 gefixt. -rwxr-x--- 1 root trusted 10864 2005-09-09 18:21 ziptool* Nochmal ohne Rechte für alle. -rwx--x--x 1 root root 1186704 2005-12-17 04:34 sperl5.8.7* -rwx--x--x 1 root root 4541 2005-10-07 18:11 keygen* Und noch zwei, die nur Ausführ-, aber keine Leserechte haben. Gruß Christian Boltz PS: Die Sterne hinter den Dateinamen sind durch meine LS_OPTIONS bedingt - bitte nicht dran stören ;-) [1] https://bugzilla.novell.com/show_bug.cgi?id=161113 [2] https://bugzilla.novell.com/show_bug.cgi?id=157814 -- "It`s not a Trick, it`s Linux"
Hallo Christian,
From: Christian Boltz [...] rpm --setperms -a wäre wohl die geschicktere Lösung ;-) (gefolgt von SuSEconfig, um /etc/permissions.* auch mit ins Boot zu bekommen) [...] # ls -l /bin/ |grep -v "rwxr-xr-x\|^l" | sort # (SUSE 10.0) [...]
Vielen Dank schon mal für Deine Antwort, ich werde mich mal mit rpm und SuSEconfig auseinandersetzen, um zu prüfen ob es damit dann auch keine Problem hinsichtlich meiner user-accounts (http/ftp-homes) geben wird. User accounts, vhosts, etc. werden nämlich über ein selbstgeschriebenes skript angelegt, welches dann ebenfalls alle rechte setzt. Grüße Maik Bader
participants (3)
-
Christian Boltz -
M. Bader -
Martin Ereth