Gibt es eine Möglichkeit in einem shell-Skript oder in einem Programm eine Paßwortabfrage zu realisieren, die die Linux-Logins verwendet? Wenn also
das Programm eine geschützte Funktion ausführt, dann soll der Benutzer
seinen Linux-Benutzernamen und sein Kennwort eingeben und das Programm
prüft, ob das richtig ist.
Acader MeyerNick1 „Authentifizierung in eigenem Programm verwenden“
.......in einem Programm eine Paßwortabfrage zu realisieren, die die Linux-Logins verwenden
Ich kann den Sinn und Zweck deiner Frage nicht nachvollziehen.
MeyerNick1 Acader „.......in einem Programm eine Paßwortabfrage zu realisieren, die die...“
Hier zwei Beispiele:
a) ich habe eine Software, die unter User abc laeuft. Zwischendurch
koennte es sein, dass er auf Daten von xyz zugreifen soll. Das darf
er aber nur, wenn er das Kennwort von xyz weiss. Also muss ich
von meiner Software aus verifizieren koennen, ob der User auch das
korrekte Passwort zum User xyz eingegeben hat.
b) in einem Webbrowser soll ein Benutzer sich gegen UNIX-Login
und Passwort authentifizieren. Er gibt seine Daten ein und z.B.
ein Skript ueberprueft, ob die Daten korrekt waren.
KarstenW MeyerNick1 „Hier zwei Beispiele: a ich habe eine Software, die unter User abc laeuft....“
zu a:)
Man kann beide User in die gleiche Gruppe aufnehmen. Bei Debian hat jeder User seine eigene Gruppe. Also wenn ein User mit Loginnamen dylan heißt, dann existiert auch noch eine Gruppe dylan in der man andere User mit aufnehmen kann.
Und man kann Schreibrechte für diese Gruppe dylan vergeben und auch nur für bestimmte Dateien.
zu b:)
Macht man so was nicht mit PHP Programmierung ?
Ich bin kein Webprogrammierer.
KarstenW MeyerNick1 „Authentifizierung in eigenem Programm verwenden“
Du könntest versuchen eine Loginshell in deinem Script zu starten:
man bash
/bin/bash -l
oder
/bin/bash --login
-l Make bash act as if it had been invoked as a login shell (see INVOCATION
below).
--login
Equivalent to -l.
Ich sehe aber darin keinen Sinn.
Die Programme werden immer mit den Rechten der jeweiligen User ausgeführt von denen sie gestartet wurden. Die Rechte werden sozusagen vererbt. Also wenn du dich in der Konsole einloggst und das jeweilige Shellscript startest, dann wird dieses Shellscript mit deinen Rechten gestartet. Das hängt alles mit dem Unix-Systemaufruf fork() und dem Systemaufruf execl() von Unix zusammen, mit denen ein neuer Prozess gestartet wird.
Du kannst aber die USER ID im Shellscript mit einer if Anweisung überprüfen und daraufhin im Programm verzweigen.
In etwa so:
if [ `$ID -u` != 0 ] ; then
echo
echo "Dieses Shellscript braucht root-Rechte !"
echo
exit 1
fi
root hat die ID 0 (NULL) . Die anderen IDs kannst du aus der Datei /etc/group herausnehmen.
Oder ein Beispiel aus dem Advanced Bash-Scripting Guide
http://www.tldp.org/LDP/abs/html/internalvariables.html#AMIROOT
Im Advanced Bash-Scripting Guide habe ich diesen Hinweis gefunden:
http://www.tldp.org/LDP/abs/html/restricted-sh.html
man bash
.....
-r If the -r option is present, the shell becomes restricted (see RESTRICTED
SHELL below).
RESTRICTED SHELL
If bash is started with the name rbash, or the -r option is supplied at invocation,
the shell becomes restricted. A restricted shell is used to set up an environment
more controlled than the standard shell. It behaves identically to bash with the
exception that the following are disallowed or not performed:
· changing directories with cd
· setting or unsetting the values of SHELL, PATH, ENV, or BASH_ENV
· specifying command names containing /
· specifying a file name containing a / as an argument to the . builtin command
· Specifying a filename containing a slash as an argument to the -p option to
the hash builtin command
· importing function definitions from the shell environment at startup
· parsing the value of SHELLOPTS from the shell environment at startup
· redirecting output using the >, >|, , >&, &>, and >> redirection operators
· using the exec builtin command to replace the shell with another command
· adding or deleting builtin commands with the -f and -d options to the enable
builtin command
· Using the enable builtin command to enable disabled shell builtins
· specifying the -p option to the command builtin command
· turning off restricted mode with set +r or set +o restricted.
These restrictions are enforced after any startup files are read.
When a command that is found to be a shell script is executed (see COMMAND EXECUTION
above), rbash turns off any restrictions in the shell spawned to execute the script.
......
PS: Kauf dir mal ein kleines Buch für die Shellprogrammierung:
Shell-Programmierung für Unix und Linux (Taschenbuch)
von Rainer Krienke (Autor)
http://www.amazon.de/Shell-Programmierung-Unix-Linux-Rainer-Krienke/dp/3446217223/ref=sr_1_1?ie=UTF8&s=books&qid=1214328290&sr=8-1
Oder wenn es ausführlich sein soll:
Shell-Programmierung: Das umfassende Handbuch (Gebundene Ausgabe)
von Jürgen Wolf (Autor)
http://www.amazon.de/Shell-Programmierung-umfassende-Handbuch-J%C3%BCrgen-Wolf/dp/3836211572/ref=sr_1_1?ie=UTF8&s=books&qid=1214328366&sr=1-1
Xdata KarstenW „Du könntest versuchen eine Loginshell in deinem Script zu starten: man bash...“
Mit den Rechten der jeweiligen User..
Das bedeutet - wenn jemand mit einer Live CD und Rootrechten ins Internet geht
könnte ein Angreifer mit einem rm -Befehl alle gemounteten Partitionen löschen?
Das default standard -Paßwort einer Live Distribution ist ja auch nicht unschwer zu ermitteln.
Eine Erweiterung des Ext3 bei red Hat, soll auch bei erlangten Rootrechten dem
entsprechenden Programm keine untypischen Aktionen erlauben.
SELinux soll aber auf einem Desktop System mehr Probleme machen als zu nützen.
Die Idee einer - sagen wir mal Klassenabstufung der Rootrechte ist nicht schlecht.
Es sollte dann aber eine Eigenschaft des Kernels sein und nicht nur für ein bestimmtes Dateisystem gehen.
Für ganz sichere Systeme wurde mal ein monolithischer Kernel genannt, der nur
ganz bestimmte Aufgaben kann und daher sicher ist.
Ob das heute noch geht?
Hier im Thread sollte ja eine Paßwortabfrage kommen wenn ein Programm eine geschützte Aktion ausführen soll.
Das ist eher abträglich,
-- jedenfalls wenn es so wie bei Vista umgesetzt wird, wo bei jeder - noch so popeligen Sache nachgefragt wird und alles abndere erstmal Blockiert ist.
KarstenW Xdata „Mit den Rechten der jeweiligen User.. Das bedeutet - wenn jemand mit einer Live...“
"Das bedeutet - wenn jemand mit einer Live CD und Rootrechten ins Internet geht
könnte ein Angreifer mit einem rm -Befehl alle gemounteten Partitionen löschen?"
Klar, deshalb soll man ja auch nicht alle Programme als root starten.
Meist ist es so das ein komprimitierter Server versucht einen Trojaner (oder andere Malware) auf dem Desktoprechner im Hintergrund zu installieren.
Wenn der Benutzer keine Programme installieren kann, dann kann der Firefox oder ein anderer Browser auch nicht genutzt werden um Schadsoftware zu installieren.
Man kann auch unter Windows XP einen Mehrbenutzermodus aktivieren, aber die meisten (Windows-)Anwender wissen nicht warum sie es machen sollen.
Ich habe aber leider schon oft erleben müssen , das man viele Windowsprogramme nur als Administrator starten kann
(obwohl das gar nicht notwendig wäre).
"Für ganz sichere Systeme wurde mal ein monolithischer Kernel genannt, der nur
ganz bestimmte Aufgaben kann und daher sicher ist.
Ob das heute noch geht?"
Du kannst dir selbst einen monolitischen Kernel übersetzen. Das wird für Internetserver immer noch empfohlen.
Monolitische Betriebsystemkerne sind nicht so leicht durch rootkits angreifbar. rootkits verändern den Programmcode (die Kernelmodule werden manipuliert) des Betriebsystemkerns, öffnen Ports so das sich ein Angreifer als root im System über Internet einloggen kann.
Xdata KarstenW „ Das bedeutet - wenn jemand mit einer Live CD und Rootrechten ins Internet geht...“
In Bezug auf Xp muß ich dir recht geben, meist haben die User gar keine
Schuld das sie als Administrator surfen (müssen) da vieles einfach nur so
geht.
Das oftgenannte -- ausführen als.. funktioniert unter Xp nie.
Bei Linux ist das kein Problem, außer - Zum Teil bei Ubuntu und Kubuntu
wegen des Umwegs über sudo.
Oft geht das garnicht da Gui-programme nicht als sudo aufgerufen werden können. Will man dann seine fstab oder xorg.conf bearbeiten muß man
den vi nehmen -- sehr schwierig. Von der Gui aus kommt man mit sudo und den gängigen Editoren nicht ran.
Nun gut, den gedit kann man auch mit sudo aus einem Konsolenfenster starten.
Er meckert, erscheint aber Rootfähig im Guifenster.
Andere der grafischen Editoren funktionieren so überhaupt nicht.
Und ehe man herausbekommen hat wie kdesu oder so geht hat man es sogar mit dem ungewohnten vi geschafft.
Da ist Debian weiter:
-- die schreiben einem keine vermeinlich sichereren, umständlichen Umwege vor.
Das sudo sicherer ist kann nur von einem Schelm stammen.
-- Das Problem - es existiert dann "nur" EIN Passwort sollte einem Bewußt sein
Borlander Xdata „In Bezug auf Xp muß ich dir recht geben, meist haben die User gar keine Schuld...“
Xdata Borlander „OT: Windows / Ausführen als“
Wirklich.. versuch das mal wenn der Realplayer sich wieder mal Updaten will.
Ich brauch den nicht unbedingt, aber einige Bekannte zB. die auf
Amazon.de Hörproben von Titeln laufen lassen.
Auch viele Brennprogramme und einiges mehr brauchen Administrative Rechte.
Wie man das mit sudo richtig macht offenbart nur der Vergleich mit Apple:
Da kann wohl man alle administrativen Augaben mit Paßwort als normaler
User erledigen.
Borlander Xdata „Wirklich.. versuch das mal wenn der Realplayer sich wieder mal Updaten will. Ich...“
Xdata Borlander „ Den habe ich schon seit bald 10 Jahren nirgendwo mehr installiert - Gab es für...“
Danke für den Hinweis, ein alternatives Format wär eine feine Sache.
Der Realplayer nerft! Die haben sich wohl bei vielen ihr Image verdorben durch den unglaublichen Updatewahn. Der Player ansich wär nichtmal so schlecht, aber die Updaterei nervt ungemein..
Habe gerade Erfahren - bei Amzon.com soll es mit dem Windows Mediaplayer gehen.
