User wechseln ("su")

[slu]

Hallo allemiteinander! :-)

Und schon wieder muss ich das Forum befragen. (Wir sind schon lästig, wir Newbes, nicht?) :))

Es geht um folgendes:
Ich würde gerne eine Datei erstellen (>Datei)(usw.), die aber leider (und das macht mir Kopfzerbrechen)
in einem Verzeichnis liegt, das nur für Bestimmte User ist. Also Passwortgeschützt!

Nun kann ich die Verzeichnisse, mit meinem jetzigen Wissensstand nur als anonymous anschauen, bzw. hineinschreiben!. Kennt vielleicht jemand das Modul, oder den Befehl, mit dem man dem User, oder dem Script andere Permissions (Userprofil oder weiss ich was) (vielleicht auch nur Zeitweise) zuteilen kann, sowas ähnliches wie "su" unter Linux. Oder kann man da sogar ein Shell-Fenster öffnen?

Ich hoffe, dass irgend jemand dieses Problem kennt und ne Lösung weiss.

Es darf auch eine kurze Notiz sein, wo ich gut dokumentierte Infos dazu bekomme! (Wie schon gesagt, ich bin Perl-Anfänger (seit ca. 2 Tagen dran))

Also vielen Dank und
Mahlzeit
Stefan Ludwig

[Peter Squentz]

Nun kann ich die Verzeichnisse, mit meinem jetzigen Wissensstand nur als anonymous anschauen, bzw. hineinschreiben!. Kennt vielleicht jemand das Modul, oder den Befehl, mit dem man dem User, oder dem Script andere Permissions (Userprofil oder weiss ich was) (vielleicht auch nur Zeitweise) zuteilen kann, sowas ähnliches wie "su" unter Linux. Oder kann man da sogar ein Shell-Fenster öffnen?

Was Du brauchst ist ein setuid-Skript. Mit "chmod 4755 skript.pl" kann ich als root oder Besitzer dafuer sorgen, dass skript.pl der Berechtigung des Besitzers von skript.pl ausgefuehrt wird, nicht mit der des ausfuehrenden Benutzers.

Ist dieser Mechanismus aus Sicherheitsgruenden fuer Skripte abgeschaltet, kann man sich eines kleinen binary's bedienen, dass das Skript mit der richtigen Berechtigung aufruft.

Peter

PS: Vorsicht, soetwas kann schaden anrichten, wenn man nicht genau weiss, was man tut.

[slu]

Hallo nochmals!

Was Du brauchst ist ein setuid-Skript. Mit "chmod 4755 skript.pl" kann ich als root oder

Besitzer dafuer sorgen, dass skript.pl der Berechtigung des Besitzers von skript.pl ausgefuehrt wird,
nicht mit der des ausfuehrenden Benutzers.

Ist dieser Mechanismus aus Sicherheitsgruenden fuer Skripte abgeschaltet,

kann man sich eines kleinen binary's bedienen, dass das Skript mit der richtigen Berechtigung aufruft.

PS: Vorsicht, soetwas kann schaden anrichten, wenn man nicht genau weiss, was man tut.

Ich suche mal nach der Verwendung von setuid in Perl und hoffe, dass ich damit das Problem
beheben kann.
Also, danke für den kleinen Tip.
Aber auch für andere Ideen, Tips, Links bin ich dankbar!

Tschüss
Stefan Ludwig

[Christoph Zurnieden]

Hallo zusammen,

Ist dieser Mechanismus aus Sicherheitsgruenden fuer Skripte abgeschaltet,
kann man sich eines kleinen binary's bedienen, dass das Skript mit der richtigen Berechtigung aufruft.

Es hat schon seinen Grund, warum sowas ausgeschaltet ist ;-)

Trotzdem hier das oben angesprochen Binarie, nein die Quellen zum Selberbauen, sollte überall kompilieren.
Das Programm führt das einkompilierte Programm (Nein, nur der Name nebst Pfad wird natürlich fest einkompiliert ;-) mit der UID aus, die es selber hat.

#include <stdio.h>
#include <stdlib.h>

#define PROGPATH "/usr/bin/perl"

#define PROGNAME "/path/to/progname"

int main(){
          execl(PROGPATH, PROGNAME, NULL);
}

Siehe auch man execl für weiter Informationen.
Es sollten die Pfade schon fest einkompiliert bleiben, evt kann über argv[] noch Argumentenübergabe praktiziert werden.

Wenn noch Fragen sind ... ;-)

so short

CZ

[slu]

Hallo zusammen,

Ist dieser Mechanismus aus Sicherheitsgruenden fuer Skripte abgeschaltet,
kann man sich eines kleinen binary's bedienen, dass das Skript mit der richtigen Berechtigung aufruft.

Es hat schon seinen Grund, warum sowas ausgeschaltet ist ;-)

Klappt aber tadellos! Ich denke mal, dass bei meiner Anwendung kein grosser Unfug getrieben werden kann.
Dofern ich es nicht selbst tue.... :-)

Trotzdem hier das oben angesprochen Binarie, nein die Quellen zum Selberbauen, sollte überall kompilieren.
Das Programm führt das einkompilierte Programm (Nein, nur der Name nebst Pfad wird natürlich fest einkompiliert ;-) mit der UID aus, die es selber hat.

#include <stdio.h>
#include <stdlib.h>

Sind das nicht C-incudes?? Ich dachte ich sei in Perl. :-) Und so gewievt, dass ich  das jetzt so könnte,
ich noch nicht.

#define PROGPATH "/usr/bin/perl"

#define PROGNAME "/path/to/progname"

int main(){
          execl(PROGPATH, PROGNAME, NULL);

»»  }

Siehe auch man execl für weiter Informationen.
Es sollten die Pfade schon fest einkompiliert bleiben, evt kann über argv[] noch Argumentenübergabe praktiziert werden.

Wenn noch Fragen sind ... ;-)

Ja, wo kann man solche Sache genauer nachlesen. Ich interessiere mich zwar sehr dafür,
aber wie schon gesagt, ich kletter noch am Fuss des Perl - Matterhorns... :-)
Aber auch dir vielen Dank für die Idee.... :)

So, auch ich,
Gruss
Stefan

[Christoph Zurnieden]

Hallo zusammen,

Es hat schon seinen Grund, warum sowas ausgeschaltet ist ;-)

Klappt aber tadellos! Ich denke mal, dass bei meiner Anwendung kein grosser Unfug getrieben werden kann.

Das Problem kommt (zumindest sollte es, sonst hast Du erkleckliche Sicherheitslücken!), wenn im Script weitere Scripte/Programme aufgerufen werden. Die werden dann nämlich mittels einer weiteren Instanz des Interpreters abgearbeitet.
Dann natürlich nicht mehr mit der geänderten UID.

Dofern ich es nicht selbst tue.... :-)

---^
schöner Typo, Absicht? ;-))

#include <stdio.h>
#include <stdlib.h>
Sind das nicht C-incudes?? Ich dachte ich sei in Perl. :-) Und so gewievt, dass ich  das jetzt so könnte,
ich noch nicht.

Das ist der berühmte suid Workaround und so am einfachsten.
Kompilieren mittels

gcc -O3 -o denkdireinennamenaus denkdireinennamenaus.c

Resultierende Binarygröße ca 800 Byte (Linux ELF)
Ich habe hier auch noch eine allgemeine Version, der man als Argument den Scriptnamen mit allen evt Argumenten übergibt.

»> Ja, wo kann man solche Sache genauer nachlesen.

War ein Fundstück aus dem Netz und ist eigentlich für Shellscripte gedacht.

Ich interessiere mich zwar sehr dafür,
aber wie schon gesagt, ich kletter noch am Fuss des Perl - Matterhorns... :-)

Wohl eher Everest ;-)

Aber auch dir vielen Dank für die Idee.... :)

Aber bitte doch, nichts zu danken.

so short

CZ

[slu]

Hallo zusammen,

Das Problem kommt (zumindest sollte es, sonst hast Du erkleckliche Sicherheitslücken!), wenn im Script weitere Scripte/Programme aufgerufen werden. Die werden dann nämlich mittels einer weiteren Instanz des Interpreters abgearbeitet.
Dann natürlich nicht mehr mit der geänderten UID.

Nee, ist nur ein kurzes, kleines Progrämmchen! Ohne weitere Programmaufrufe, etc... :-)
Aber, wenn ich mal ein grösseres Projekt in Perl vorhabe, was durchaus möglich ist:
Ich wurde, soviel ich weiss, von dem berüchtigten Perl-Virus infiziert: Befällt Computer wie Menschen. *grins*

• dann werd ich mir mal Gedanken über das Studio, ähh, stdio.h machen :-)

Dofern ich es nicht selbst tue.... :-)
---^
schöner Typo, Absicht? ;-))

Klar, ich leide unter Minderwertigkeitskomplexen!!!! ;)

#include <stdio.h>
#include <stdlib.h>
Sind das nicht C-incudes?? Ich dachte ich sei in Perl. :-) Und so gewievt, dass ich  das jetzt so könnte,
ich noch nicht.

Das ist der berühmte suid Workaround und so am einfachsten.
Kompilieren mittels

gcc -O3 -o denkdireinennamenaus denkdireinennamenaus.c

I'll see. (Ich glaub kurz IC, hm?)

Resultierende Binarygröße ca 800 Byte (Linux ELF)
Ich habe hier auch noch eine allgemeine Version, der man als Argument den Scriptnamen mit allen evt Argumenten übergibt.

Ich werds mir merken!!!

aber wie schon gesagt, ich kletter noch am Fuss des Perl - Matterhorns... :-)

Wohl eher Everest ;-)

Wieso, ich komme aus der Schweiz.... :-} :)

Also, danke nochmals und vielleicht wieder mal in Sachen Perl

Stefan Ludwig

[Michael Schröpl]

Hi,

#include <stdio.h>
#include <stdlib.h>
Sind das nicht C-incudes?? Ich dachte ich sei in Perl. :-) Und so gewievt, dass ich  das jetzt so könnte,
ich noch nicht.

Das Problem ist eben, daß Dein Problem in Perl nicht lösbar ist, *wenn* das s-Bit für Skripte disabled ist.
(Ich mußte bei der Portierung von AIX 3 nach 4 einen Haufen Skripte in solche Binaries umschreiben, weil IBM das s-Bit beim Versionsumstieg als "Sicherheitslücke" gekündigt hatte ...)

Das s-Bit bewirkt, daß das ausgeführte Programm vom Betriebssystem unter der Kennung seines Owners ausgeführt wird.
Aber Dein Perl-Skript ist *nicht* das ausgeführte Programm - sondern der Perl-Interpreter! (Und dem willst Du ja bestimmt kein s-Bit geben, weil das für alle Perl-Skripte einheitlich ausgewerten würde ...)
Das Problem existiert also für alle Skipt-Sprachen (in meinem Fall waren es shell-Skripte, die ohne s-Bit ebefnalls nicht mehr korrekt funktionierten).

mfG - Michael