On Tue, 11 Jan 2000, you wrote:
#!/bin/sh exec Program Parameter
Was macht das Proggy denn ?
Je nach Login unterschiedlich. Entweder telnet mudserver mudport oder terminal_mudclient mudserver mudport
*grins*
Wie gesagt, das Login hat kein Passwort, da das jeder nutzen können soll.
Logo ...
Telnet/SSH soll möglich sein.
Wie telnet ? also letztendlich ist Proggy doch eine Shell ?
Nee, er soll das Prog auch remote nutzen können, mit SSH oder halt Telnet.
Nun ist das ja ein kleines/großes Sicherheitsloch, und ich will das jetzt absichern.
Kommt drauf an, auf Proggy ! Wenn's 'ne Shell ist, ist es gross - wenn's 'ne MessageBox ist klein!
Das Proggie darf natürlich keine Bugs haben (StackOverflow etc.) Wenn einen Segfault macht fliegt er ja raus ...
Auf keinen Fall wuerde ich diesen boesen Buben auf meine Platte schauen lassen, er bekommt ein eigenes kleines nettes nach meinen Beduerfnissen minimiertes Environment. chroot /eigenes/root/file/system
Das ist ne gute Idee ...
Da kann man nun /bin, /usr/bin, usw. anlegen und halt alles drauftun, was der Knabe braucht, ohne staendig Panik zu haben. Uebrigens macht ftp das auch so!
Ja, klar.
Weiß jemand wie man das mit Last login .... abstellt ?
man bash ?
Nix gefunden (schlecht gesucht)
- ftpzugang nicht möglich: echo "User" >> /etc/ftpusers
Warum eigentlich nicht, da hast Du ihn doch auch unter Kontrolle ... halt wie 'anonymous'
Ich will nicht das jemand an den Configdateien rumspielt, es sollen nur viele verschiedene Nutzer den Service nutzen können ....
Wie kann ich folgendes möglichst einfach (transparent) einstellen/konfigurieren ?
- Mail senden/empfangen nicht möglich
Gib ihm kein Mailprogramm.
Das meinte ich nicht. Man kann dem Login dann noch Mail senden, da will ich auch nicht ...
- HTTP/CGI nicht möglich
Gib ihm keinen Browser
Meinte ich auch nicht. ~/public_html und ~/public_html/cgi-bin Hier kommt sicher der apache ins Spiel.
- Loginshell ändern nicht möglich
Ist nicht ... und selbst wenn, passwd kennt er nicht mehr !
Ok.
- Anzahl der gleichzeitigen logins beschränken, wegen DOS-Attacke
(das Programm würde ja jedesmal gestartet, nimmt zwar nicht viel Resourcen weg, aber immerhin ...)
Da koentest Du z.B. eine Datei im HOME anlegen. Der .login script sollte sich darin anmeldenderweise eintragen, der .logout sollte sich dann abmeldenderweise austragen.
Ja, bei gleichzeitigem login etwas schwierig, mal sehen ...
Was sollte man noch alles machen ?
Bleibt fuer mich die Frage, was eigentlich soll der Nutzer machen ? Schliesslich hast Du ihm nun wirklich fast alles verboten ... na gut $> export Windows=GrosserMist
Das kann er auch nicht, da es keine Shell ist :)
sollte noch gehen ... aber ob das jemanden echt begeistert ?
Soll ja nur das Programm benutzen ...
-- Stephan Götter sg17@inf.tu-dresden.de
Die Ausgabe wurde aufgrund von Windows-Beschränkungen abgeschnitten.