Bash: im Script User wechseln
Bernd Hohmann
Kann man in einem Bash-Script "Userhopping" betreiben - also mitten drin
den User wechseln, die nächsten Zeilen werden dann unter einem anderen
User ausgeführt und dann wieder zurückwechseln?
Bernd
--
Visit http://www.nixwill.de and http://www.spammichvoll.de
jean....@nixwill.de & bernado....@spammichvoll.de
Marcel Bruinsma
> Kann man in einem Bash-Script "Userhopping" betreiben - also mitten
> drin den User wechseln, die nächsten Zeilen werden dann unter einem
> anderen User ausgeführt und dann wieder zurückwechseln?
Wenn das Script von root gestartet wurde:
su -m USER <<EOF (oder <<-EOF oder <<\EOF)
commandA
commandB
usw.
EOF
Sonnst:
su -mc " (oder halbe Anführungszeichen oder gar keine)
commandA
commandB
usw.
" USER
In beiden Fälle startet aber ein neuer Shell, der die Variablen
des Elternteils nicht ändern kann. Vermutlich möchtest Du
gerade das. In perl oder C mit seteuid() kein Problem, aber
in einem sh-Script…
--
printf -v email $(echo \ 155 141 162 143 145 154 142 162 165 151 \
156 163 155 141 100 171 141 150 157 157 056 143 157 155|tr \ \\\\)
# Live every life as if it were your last! #
Marcel Bruinsma
> Am Mittwoch, 21. Oktober 2009 22:18, Bernd Hohmann a écrit :
>
>> Kann man in einem Bash-Script "Userhopping" betreiben
> [...]
> In perl oder C mit seteuid() kein Problem, aber in einem sh-Script…
Quatsch, in der Zsh geht das natürlich mit EUID=<user-id>.
Vielleicht klappt's in Bash genau so.
Bernd Hohmann
> Wenn das Script von root gestartet wurde:
>
> su -m USER <<EOF (oder <<-EOF oder <<\EOF)
> commandA
> commandB
> usw.
> EOF
Tatsach... Wieso lief das in meinem Test nicht?
Vermutlich weil ich das nur testen wollte und eine Konstruktion der Sorte
eval << EOF
command...
EOF
probierte. Hast Du noch einen Tipp wie man das ausserhalb von su testen
kann?
> In beiden Fälle startet aber ein neuer Shell, der die Variablen
> des Elternteils nicht ändern kann. Vermutlich möchtest Du
> gerade das.
Nö. Es geht nur um die Konsolidierung einer Kette
"root/user/root/user/root/user..." (hat man bei IPTABLES und VirtualBox
recht schnell).
Danke,
Marcel Bruinsma
> Marcel Bruinsma schrieb:
>
>> su -m USER <<EOF (oder <<-EOF oder <<\EOF)
>
> Hast Du noch einen Tipp wie man das ausserhalb von su
> testen kann?
Zuerst 'cat <<EOF', wenn die Ausgabe zufrieden stellt
vielleicht noch 'bash <<EOF'.
Bernd Hohmann
>>> su -m USER <<EOF (oder <<-EOF oder <<\EOF)
>>
>> Hast Du noch einen Tipp wie man das ausserhalb von su
>> testen kann?
>
> Zuerst 'cat <<EOF', wenn die Ausgabe zufrieden stellt
> vielleicht noch 'bash <<EOF'.
Hab Dank!
Juergen Ilse
Bernd Hohmann <bernd.hohma...@freihaendler.com> wrote:
> Kann man in einem Bash-Script "Userhopping" betreiben - also mitten drin
> den User wechseln, die nächsten Zeilen werden dann unter einem anderen
> User ausgeführt und dann wieder zurückwechseln?
So einfach wohl eher nicht, denn die shell in der das script ausgefuehrt
wird, wird nicht den Benutzer wechseln ... Man koennte aber z.B. etwas
wie
sudo /bin/sh -c "cmd1; cmd2; cmd3"
oder dergleichen verwenden ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Juergen Ilse
Marcel Bruinsma <m...@nomail.afraid.org> wrote:
> Am Mittwoch, 21. Oktober 2009 23:27, Marcel Bruinsma a écrit :
>> Am Mittwoch, 21. Oktober 2009 22:18, Bernd Hohmann a écrit :
>>> Kann man in einem Bash-Script "Userhopping" betreiben
>> [...]
>> In perl oder C mit seteuid() kein Problem, aber in einem sh-Script…
> Quatsch, in der Zsh geht das natürlich mit EUID=<user-id>.
> Vielleicht klappt's in Bash genau so.
Das umsetzen der Environmentvariable EUID aeendert nicht die Zugriffsrechte
fuer die nachfolgenden Befehle /was wohl der Zweck des ganzen sein soll),
also ist deine Loesung keine ...
Marcel Bruinsma
> Marcel Bruinsma <m...@nomail.afraid.org> wrote:
>
>> Quatsch, in der Zsh geht das natürlich mit EUID=<user-id>.
>
> Das umsetzen der Environmentvariable EUID aeendert nicht die
> Zugriffsrechte fuer die nachfolgenden Befehle /was wohl der Zweck des
> ganzen sein soll), also ist deine Loesung keine ...
« EUID
» The effective user ID of the shell process. If you have
» sufficient privileges, you may change the effective user
» ID of the shell process by assigning to this parameter. »
Wer lesen kann…
→ printf '%u %u %u\n' $(id -ru) $(id -u) $EUID
0 0 0
→ EUID=${${(s(:))$(getent passwd news)}[3]}
→ printf '%u %u %u\n' $(id -ru) $(id -u) $EUID
0 9 9
→ ls /root/.exrc
ls: ne peut accéder /root/.exrc: Permission non accordée
→ EUID=${${(s(:))$(getent passwd root)}[3]}
→ printf '%u %u %u\n' $(id -ru) $(id -u) $EUID
0 0 0
→ ls /root/.exrc
/root/.exrc
Wer tippen kann… :-)
Zugriffsrechte werden von der »effective user-id« (euid)
bestimmt, nicht von der »real user-id.« Deswegen gibt
es access(2) für set-uid Programme.
Juergen Ilse
Marcel Bruinsma <m...@nomail.afraid.org> wrote:
> Am Donnerstag, 22. Oktober 2009 03:36, Juergen Ilse a écrit :
>> Marcel Bruinsma <m...@nomail.afraid.org> wrote:
>>> Quatsch, in der Zsh geht das natürlich mit EUID=<user-id>.
>> Das umsetzen der Environmentvariable EUID aeendert nicht die
>> Zugriffsrechte fuer die nachfolgenden Befehle /was wohl der Zweck des
>> ganzen sein soll), also ist deine Loesung keine ...
> « EUID
> » The effective user ID of the shell process. If you have
> » sufficient privileges, you may change the effective user
> » ID of the shell process by assigning to this parameter. »
> Wer lesen kann…
Welch furchtbar uebler Hack ...
Der entscheidende Teilsatz lautet dabei "If you havesufficient privileges"
und der trifft eben *nicht* zu, wenn man mit normalen User-Rechten
startet (wie vom OP beschrieben).
> Zugriffsrechte werden von der »effective user-id« (euid)
> bestimmt, nicht von der »real user-id.« Deswegen gibt
> es access(2) für set-uid Programme.
Richtig. Und? Das Problem des OP wird dadurch noch nicht geloest, da
er nicht mit root-Rechten startet. Bei der bash ist EUID uebrigens
(sinnvollerweise) readonly ...
Bernd Hohmann
> Der entscheidende Teilsatz lautet dabei "If you havesufficient privileges"
> und der trifft eben *nicht* zu, wenn man mit normalen User-Rechten
> startet (wie vom OP beschrieben).
Das habe ich nirgendwo gesagt - ich kann das auch als Root starten, wenn
es das Problem löst - wichtig ist nur, dass ich den User wechseln kann.
Marcel Bruinsma
> Das Problem des OP wird dadurch noch nicht geloest, da er
> nicht mit root-Rechten startet.
Systemabhängig: linux beachtet CAP_SETUID; 'privileged'
im Sinne von seteuid(2) sind alle Prozesse die über diese
Kapazität verfügen. Andere Systeme fordern tatsächlich
euid == 0. IEEE Std 1003.1 spricht nur von 'privileges',
alles andere wird den Implementationen überlassen.
Bernd (der OP) hat weder das System, noch die Art der
Zugriffsrechte des Scripts erwähnt. Welche Alternative
(su, sudo oder seteuid) in /seinem/ besonderen Fall
besser geeignet ist, kann nur /er/ entscheiden. /Wir/
können (und sollten) nur denkbare Lösungen reichen.
Bei Bedarf (d. h. falls die Entscheidung ihm schwer
fällt) könnte er eine detaillierte Nachfrage stellen.
Dafür wurde das Usenet erfunden. ;-)
> Bei der bash ist EUID uebrigens (sinnvollerweise) readonly ...
Meinst Du, kein Prozess solle die effective user-ID wechseln
dürfen? Kann aber manchmal sehr nützlich sein. Man sollte
aber die potenzielle Gefährdung der Sicherheit gut im Auge
behalten. Am häufigsten dürfte eine Lösung mit fork(2) und
setuid(2) besser passen. Auch dafür braucht man allerdings
'privileges':
→ stat -c'%A %U %n' $(which su sudo)
-rwsr-xr-x root /bin/su
-rwsr-xr-x root /usr/bin/sudo
Ferry Bolhar
> ? EUID=${${(s(:))$(getent passwd root)}[3]}
Was f�r eine Syntax bzw. Shell ist das? Meine bash (Version 3.2.39(1)) mag
die nicht:
-bash: echo ${${(s(:))$(getent passwd news)}[3]}: bad substitution
LG, Ferry
--
Ing. Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolh...@wien.gv.at
Marcel Bruinsma
> "Marcel Bruinsma":
>
>> → EUID=${${(s(:))$(getent passwd root)}[3]}
>
> Was für eine Syntax bzw. Shell ist das?
/bin/zsh (man 1 zshexpn zshparam)
Markus Wichmann
> "Marcel Bruinsma":
>
>> ? EUID=${${(s(:))$(getent passwd root)}[3]}
>
>
> -bash: echo ${${(s(:))$(getent passwd news)}[3]}: bad substitution
>
> LG, Ferry
>
Das ist zsh und bedeutet: Nimm die Ausgabe von "getent passwd root",
betrachte ":" als Feldtrenner und nimm das dritte Element. Für die bash
also
EUID=$(getent passwd root | cut -d: -f3)
Unterschied: Die bash braucht dafür externe Tools.
HTH,
Markus
--
Nur weil ein Genie nix reißt, muß ja nun nicht gleich jeder Idiot
pausieren... Bully hats ja auch geschafft.
-- gUnter nanonüm in de.alt.anime
Heike C. Zimmerer
> Ferry Bolhar (b...@adv.magwien.gv.at) schrieb:
>>> ? EUID=${${(s(:))$(getent passwd root)}[3]}
>
> Das ist zsh und bedeutet: Nimm die Ausgabe von "getent passwd root",
> betrachte ":" als Feldtrenner und nimm das dritte Element. F�r die bash
> also
>
> EUID=$(getent passwd root | cut -d: -f3)
>
> Unterschied: Die bash braucht daf�r externe Tools.
Wirklich? Dass Du externe Tools brauchst, hei�t nicht notwendigerweise,
dass die Bash externe Tools daf�r braucht.
[[ $(getent passwd root) =~ ^([^:]+:){2}([^:]+) ]]; echo ${BASH_REMATCH[2]}
braucht keine externen Tools, tut dasselbe und ist in etwa genauso w�st
zu lesen.
Gru�,
Heike
Helmut Hullen
Du meintest am 24.10.09:
>> EUID=$(getent passwd root | cut -d: -f3)
>>
>> Unterschied: Die bash braucht daf�r externe Tools.
> Wirklich? Dass Du externe Tools brauchst, hei�t nicht
> notwendigerweise, dass die Bash externe Tools daf�r braucht.
> [[ $(getent passwd root) =~ ^([^:]+:){2}([^:]+) ]]; echo
> ${BASH_REMATCH[2]}
> braucht keine externen Tools, tut dasselbe und ist in etwa genauso
> w�st zu lesen.
Schick!
Gibt es irgendwo einen "obfuscated bash code contest"?
Siehe http://www.ioccc.org/
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Markus Wichmann
> Markus Wichmann <null...@gmx.net> writes:
>
>> Ferry Bolhar (b...@adv.magwien.gv.at) schrieb:
>
>>>> ? EUID=${${(s(:))$(getent passwd root)}[3]}
>>
>> Das ist zsh und bedeutet: Nimm die Ausgabe von "getent passwd root",
>> also
>>
>> EUID=$(getent passwd root | cut -d: -f3)
>>
>
> Wirklich? Dass Du externe Tools brauchst, heißt nicht notwendigerweise,
> dass die Bash externe Tools dafür braucht.
>
> [[ $(getent passwd root) =~ ^([^:]+:){2}([^:]+) ]]; echo ${BASH_REMATCH[2]}
>
> zu lesen.
>
Dem letzten Teilsatz kann ich nicht zustimmen.
Aber natürlich kann man das auch mit der POSIX-sh machen: Das dritte
Feld von links bedeutet, dass man zwei Felder von links und alle Felder
von Rechts löschen muss:
LINE=$(getent passwd root)
LINE=${LINE#*:}
LINE=${LINE#*:}
LINE=${LINE%%:*}
EUID=$LINE
braucht ebenfalls keine externen Tools und ist nicht ganz so wüst zu
lesen, vorausgesetzt man kennt die Bedeutung von ${name#pattern}. Ich
gebe zu, ich musste selbst erst nachlesen, in welcher Form das pattern
greedy ist und in welcher nicht.
>
> Gruß,
>
> Heike
Tschö,
Helmut Hullen
Du meintest am 25.10.09:
>>> EUID=$(getent passwd root | cut -d: -f3)
>> [[ $(getent passwd root) =~ ^([^:]+:){2}([^:]+) ]]; echo
>> ${BASH_REMATCH[2]}
>>
>> braucht keine externen Tools, tut dasselbe und ist in etwa genauso
>> w�st zu lesen.
> LINE=$(getent passwd root)
> LINE=${LINE#*:}
> LINE=${LINE#*:}
> LINE=${LINE%%:*}
> EUID=$LINE
> braucht ebenfalls keine externen Tools und ist nicht ganz so w�st zu
> lesen,
Wenn Mehrzeiler erlaubt sind:
set -- $(getent passwd root | tr ':' ' ')
EUID=$3
Bei so sicheren Vorlagen erspare ich mir die Bastelei mit IFS.
Ok - ist nicht mehr "obfuscated".
Heike C. Zimmerer
> Aber nat�rlich kann man das auch mit der POSIX-sh machen: Das dritte
> Feld von links bedeutet, dass man zwei Felder von links und alle Felder
> von Rechts l�schen muss:
>
> LINE=$(getent passwd root)
> LINE=${LINE#*:}
> LINE=${LINE#*:}
> LINE=${LINE%%:*}
> EUID=$LINE
>
> braucht ebenfalls keine externen Tools und ist nicht ganz so w�st zu
> lesen,
Na siehst Du, auch Du bringst was ohne externe Tools zustande. Geht
doch. Wozu also erst behaupten, es ginge nicht ohne?
Eine L�sung, die mir besser gef�llt, sieht z.B. so aus:
IFS=: read x x euid x <<EOF
$(getent passwd)
EOF
Gru�,
Heike
Heike C. Zimmerer
> Aber nat�rlich kann man das auch mit der POSIX-sh machen: Das dritte
> Feld von links bedeutet, dass man zwei Felder von links und alle Felder
> von Rechts l�schen muss:
>
> LINE=$(getent passwd root)
> LINE=${LINE#*:}
> LINE=${LINE#*:}
> LINE=${LINE%%:*}
> EUID=$LINE
>
> braucht ebenfalls keine externen Tools und ist nicht ganz so w�st zu
> lesen,
Na siehst Du, auch Du bringst was ohne externe Tools zustande. Geht
doch. Wozu also erst behaupten, es ginge nicht ohne?
Eine L�sung, die mir besser gef�llt, sieht z.B. so aus:
IFS=: read x x euid x <<EOF
$(getent passwd root)
EOF
Gru�,
Heike
Bernd Nawothnig
>>> EUID=$(getent passwd root | cut -d: -f3)
>>> Unterschied: Die bash braucht dafür externe Tools.
>> Wirklich? Dass Du externe Tools brauchst, heißt nicht
>> notwendigerweise, dass die Bash externe Tools dafür braucht.
>> [[ $(getent passwd root) =~ ^([^:]+:){2}([^:]+) ]]; echo
>> ${BASH_REMATCH[2]}
>> braucht keine externen Tools, tut dasselbe und ist in etwa genauso
>> wüst zu lesen.
> Schick!
> Gibt es irgendwo einen "obfuscated bash code contest"?
Böse Zungen sagen ja, Shellcode sei - ähnlich wie Perl -
auto-obfuscated. Aber sowas würde mir natürlich nie nicht einfallen zu
sagen. Insbesonder nicht hier.
Natürlich nicht.
Bernd ;-)
--
No time toulouse
Martin Vaeth
>
>>>> EUID=$(getent passwd root | cut -d: -f3)
>
>
>>> Wirklich? Dass Du externe Tools brauchst, heisst nicht
>>> notwendigerweise, dass die Bash externe Tools dafuer braucht.
>
>>> [[ $(getent passwd root) =~ ^([^:]+:){2}([^:]+) ]]; echo
>>> ${BASH_REMATCH[2]}
>
>>> braucht keine externen Tools, tut dasselbe und ist in etwa genauso
>
>> Schick!
>> Gibt es irgendwo einen "obfuscated bash code contest"?
>
> auto-obfuscated. Aber sowas wuerde mir natuerlich nie nicht einfallen zu
> sagen. Insbesonder nicht hier.
Und schon gar nicht in dem Kontext, da es auch klar geht,
und das natuerlich mit POSIX-Mitteln:
a=`getent passwd root`; a=${a#*:}; a=${a#*:}; a=${a%%:*}
printf '%s' "$a"
Nur den eigentlichen Punkt, naemlich Wechseln des Benutzers
beherrscht halt die zsh als einzige Shell.
Wie ueblich gilt: Fuer einfache Sachen nimmt man POSIX,
wenn man Luxus will/braucht zsh. Die bash enthaelt i.W. nur
Varianten zusaetzlich, die - verglichen mit zsh - umstaendlich
und trotzdem nicht annaehernd so maechtig sind.
Martin Vaeth
>>
>> su -m USER <<EOF (oder <<-EOF oder <<\EOF)
>> commandA
>> commandB
>> usw.
>> EOF
>
> Tatsach... Wieso lief das in meinem Test nicht?
Das ist eine Frage der Rechte - so ein Problem hatte ich mit sudox,
als ich einen Ansatz aehnlich dem von sux versuchen wollte, das die
X-Authority Daten ueber eine Pipeline schickt: Die interne Pipeline,
die von "<<" aufgebaut wird (und deren genauer Mechanismus vermutlich
von Shell und System abhaengt) hat moeglicherweise keine Leserechte
fuer den Benutzer USER. Ich kenne bis heute keine allgemeine Loesung
fuer das Problem.