PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : KDE-Control-Center Konfigdatei schützen?


antimon
19.01.00, 09:06
Hi,

ich habe folgendes Problem:

bei uns in der Schule stehen 10 Linux-Rechner, mit denen die Schüler surfen können. Diese betreue ich.
Leider wird daran viel rumgespielt, deshalb möchte ich die Sprache, den Bildschirmschoner etc. fest einstellen.
Leider weiss ich nicht, in welche Konfigurationsdatei KDE diese Infos abspeichert. Kann mir da jemand helfen?

Wenn ich die Datei habe, langt es dann, die Userrechte so zu ändern, dass niemand ausser Root Schreibzugriffe hat, oder läuft dann das System nicht mehr?
Gibt es vielleicht eine elegantere Möglichkeit, die Rechte so zu ändern, dass die User nicht immer die Sparche, den Bildschirmschoner und sonstiges ändern können??

Thx im Voraus,

Antimon

Hein
19.01.00, 09:51
Hi Antimon!

Du könntest natürlich jeden User einzeln im System registrieren, so daß er sein eigenes home-Verzeichnis, sein eigenes Passwort und damit auch seine eigenen kde-Einstellungen hat. Aber ich denke, das wäre für Deine speziellen Bedürfnisse zu aufwendig.

Die generellen Konfigurationsdateien für kde findest Du im Verzeichnis /opt/kde/share/config/ (bzw. /usr/local/kde/share/config/, je nach Distribution). Die lokalen Einstellungen für die User finden sich im jeweiligen Homeverzeichnis unter $home/.kde/share/config/ (Achtung, das Verzeichnis .kde ist "versteckt"!)

Wenn Du alles so einstellst, wie Du es haben möchtest und dann die Zugriffsrechte für sämtliche Dateien in diesen Unterverzeichnissen so einstellst, daß nur root Schreibrechte hat, müßte es eigentlich gehen.

Wenn Du nur bestimmte Sachen gegen Änderungen schützen willst, solltest Du Dir im Verzeichnis $home/.kde/share/config/ mal die *rc-Dateien in Ruhe durchsehen und nur die Dateien "sperren", die die entsprechenden Optionen beinhalten. Das ist relativ einfach, da die Dateien Klartext beinhalten.

Viel Erfolg
Hein

Hagen von Tronje
19.01.00, 21:35
Hi antimon,

da die kisten quasi oeffentlich sind,
solltest Du zuerst einmal das notwendige
veranlassen:
BiOS-Passwort setzen,
Lilo-Passwort setzen,
A,C im Bios disablen,
die virtuellen Konsole (1 bis 7) disablen
etc.

Was die KDE-Config betrifft, genuegt es NICHT,
die userrechte zuaendern,
da ja das Verzeichnis dem user gehoert,
und er/sie nur die Datei zu loeschen braucht
und neu anzulegen.
Deshalb muss das das Verzeichnis schreibgeschuetzt werden und das
darueberliegende und das darueberliegende
bis die userIn keinen Rechte mehr hat und
z. B. kviewrc aendern kann http://www.linuxforen.de/ubb/smile.gif

Hagen

robert
19.01.00, 22:09
Hallo!

Hagen, tut mir leid dir wiedersprechen zu müssen.

Auf alle Dateien die geschützt werden sollen einfach folgendes:

chown root <datei> (evtl. chown root:groupname)
chmod og=r <datei>

Schon kann dir kein User mehr die Datei löschen, denn Root-Dateien können auch nur von Root gelöscht werden!

Schönen Gruß

P.S.
Wenn man ganz sicher gehen will, läßt man beim Start oder per Cron jeden Tag ein Script drüber laufen.
Das mache ich so, um grundsätzlich in bestimmten Verzeichnissen User/Group-Name und Zugriffsrechte zu setzen. Das läuft alle 8 Stunden durch. Falls mal was neues hinzukommt, kann man sicher sein das die Rechte innerhalb von 8 Stunden auf jeden Fall stimmen!


[Diese Nachricht wurde von robert am 20. Januar 2000 editiert.]

Hagen von Tronje
20.01.00, 22:42
Nein ! http://www.linuxforen.de/ubb/wink.gif

Wenn root in mein home-verzeichnis ein
Dateichen reinschreibt, loesche ich es
als _normaluser_ !!!
-rw------- 1 root root 316 Jan 20 23:29 test
rm test
rm: remove `test', overriding mode 0600? y

Asta la vista Baby!

Und das $HOME/.kde , $HOME/.kde/share, $HOME/.kde/share/config, $HOME/.kde/share/config/kviewrc
MYHOMELAND sind und nicht
z. B. /tmp oder / oder sonstwas
geht das.

http://www.linuxforen.de/ubb/smile.gif

Hagen

Ausnahmen
sind /tmp oder _win-Verzeichnisse
oder Extra-Bits, die Root gesetzt haben muss.
Aber ein normale root-Datei mit
write-permission fuer mich im directory
loesche ich als user.

robert
21.01.00, 13:32
Uppsss.... du hast natürlich recht!

Ich hab mich selber etwas überlistet!

Ich hab noch mal nachgeschaut was ich für Rechte vergeben habe.

Ich hab den BESITZER des entsprechenden Verzeichnises auf ROOT geändert.
Somit können Dateien, die dem User gehören, beschrieben und verändert werden, aber nicht gelöscht. Allerdings in dem Verzeichnis auch keine neuen Dateien/Verzeichnisse angelegt werden. Was für die Situation auch ok so war. http://www.linuxforen.de/ubb/smile.gif

Dadurch konnte natürlich auch die Root-Datei nicht gelöscht werden! http://www.linuxforen.de/ubb/wink.gif

Gruß

Robert

antimon
21.01.00, 19:46
Ah ja.

Leider bin ich noch nicht (viel) weiter... :-(

Ich habe zwar schon die Rechte dür das passwd-Programm geändert, weil es bei uns einen User gibt, für den alle das Passwort kennen, um sich einzuloggen. Einige, die sich etwas mit Linux auskennen, haben dann die Passwörter geändert...
Jetzt hat keiner mehr Zugriff auf passwd.

Allerdings verändern einige User noch gerne die Sprache von KDE und setzen ein Bildschirmschonerpasswort ein.

Was ich schon versucht habe, zu machen, ist, einfach die Rechte für das KDE-Kontrollzenter zu ändern, dass es nicht mehr aufgerufen werden kann. Meint Ihr, das hilft??

Am liebsten wäre es mir, wenn ich wüsste, in welche Datei(en) die KDE-Kontrollzenterdaten hineingeschrieben werden... dann würde ich die Rechte ändern und die Sache wäre gegessen, denn ich denke nicht, dass die die Dateien löschen...
Leider habe ich bis jetzt noch nichts gefunden, vielleicht kann mir jemand weiterhelfen...

Eine andere Möglichkeit wäre, die Home-Directory-Dateien regelmässig zu löschen und mit den Standarteinstellungen zu überschreiben.
Leider weiss ich nicht, wie ich den Befehl in der Crontab (ist das überhaupt die richtige Datei?) eingibt.
Ich möchte das Verzeichnis /home/user regelmässig inklusive aller Unterverzeichnisse und versteckten Dateien löschen und danach die Dateien aus /home/usertemp in das Verzeichnis kopieren.
Könnte mir jemand sagen, wie ich das am besten anstelle (ich verwende übrigens SuSE 6.1)

Many thanx im voraus ;-)

Antimon

Hagen von Tronje
22.01.00, 02:07
Hi antimon,

> Meint Ihr, das hilft??

Ein bisschen http://www.linuxforen.de/ubb/smile.gif

Die Sprachen (und anderes) werden in die
Datei
$HOME/.kderc
geschrieben.

Wenn, dann sollte auch diese Datei "gesichert" vor
den kleinen RackerInnen http://www.linuxforen.de/ubb/biggrin.gif

Ich wuerde es so machen:

Einen neuen "surfer" user sauber anlegen.
Anschliessend:

chown -R root.sys /home/user
chmod 1777 /home/user

Somit duerfen die Kleinen auch noch ein paar
schoene Programme (und das ist besser als SURFEN )
schreiben
#include <stdio.h>

int main(void)
{
printf( "Hallo antimon!\n" ) ;

return 0 ;
}
Hagen


[Diese Nachricht wurde von Hagen von Tronje am 22. Januar 2000 editiert.]

robert
22.01.00, 17:22
Hallo Antimon!

Also für dein Script hier kurz ein kleines beispiel:


#!/bin/sh
#
# Script zum ReAnimieren eines verhunzten User-Verzeichnisses! :-)
#
UserSrc=/root/orig-user.tar.gz
dDest=/home/username

# nun wollen wir erst mal das alte Verzeichnis löschen...
cd $dDest
rm -rf *

# und jetzt orig. Verzeichnis wieder herstellen
tar -xzf $UserSrc

# das war es schon...
exit 0


Das schreibst du jetzt z.B. als Datei resetuser in das /root/bin Verzeichnis und gibst im noch die Ausführungsrechte für root (chmod 700 /root/bin/resetuser).

Wie Hagen schon schrieb, erstellst du vorher ein sauberes User-Verzeichnis.
Dieses packst du dann z.B. als /root/orig-user.tar.gz ein (cd /home/username; tar -cvzf /root/orig-user.tar.gz).
Natürlich solltest du noch sämtliche Programme für normale User unzugänglich (sprich Rechte vergeben) machen, damit (wie du schon beschrieben hast) das PW nicht gändert werden kann, oder anderes.

Du kannst das Script jetzt grundsätzlich beim Einlogen des Users starten (das solltest du aber schon vor dem Einpacken z.B. in die /home/username/.bashrc eingetragen haben, da es ja sonst wieder überschrieben wird...) oder es beim System-Start aufrufen. Beim System-Start ist natürlich in sofern schlecht, da sich ja inzwischen zig User eingelogt haben können.
Oder eben mit Cron, das hat aber den Nachteil, das du zufällig gerade alles übeschreibst, wenn jemand eingelogt ist (es sei den du setzt die Zeiten eben so, das dann niemand eingelogt ist). Das kann man zwar noch im Script oben verbessern, indem man einfach vor dem Überschreiben prüft, ob gerade dieser eine User eingelogt ist. Wenn natürlich jemand sich nicht auslogt, nutzt das auch wieder nicht. Aber dafür kann man den User auch automatisch nach einer bestimmen Inaktivität rausschmeißen und dann das Verzeichnis überschreiben. Da gibt es viele Möglichkeiten!


Gruß

Robert

P.S.
Wenn du so auch nicht weiter kommst, melde dich mal per Mail!

antimon
22.01.00, 18:30
Super!!!

Danke für Eure prompten Antworten!!!

Am Montag werde ich es ausprobieren und Euch mitteilen, wie es so läuft.

Weiter so!!!

Thx,
Antimon

Hagen von Tronje
23.01.00, 06:01
Hi,

gemein wie ich bin erwaehne ich noch,
dass Roberts script
NICHT
funktioniert http://www.linuxforen.de/ubb/biggrin.gif

Erstens mit
rm -rf *
werden die Punktdateien nicht geloescht,
und 2. werden jene
gar nicht eingepackt (!)
[und auf die kommt es ja schliesslich an]
wenn mensch mittels
cd /home/username
sich dorthin begibt.
*g*

cd /
tar -cvzf /root/orig-user.tar.gz /home/username

bzw.

cd /
rm -rf /home/username
tar -xzvf /root/orig-user.tar.gz

und alles wird gut (TM)

Hagen

PS
Das script in /home/username/.bashrc reinschreiben ist
auch keine gute Idee,
da 'username' es dort wieder aendern koennte
und user grundschaetzlich keinen
Zugriff auf
/root
und darunterliegende Dateien/Verzeichnissse
haben sollten!

[Diese Nachricht wurde von Hagen von Tronje am 23. Januar 2000 editiert.]

robert
24.01.00, 13:26
Jepp, Hagen!

Stimmt! Feinarbeiten überlaß ich anderen und Mensch will ja noch etwas mitdenken!

Sonst muß ich ja an alles denken! http://www.linuxforen.de/ubb/smile.gif http://www.linuxforen.de/ubb/smile.gif http://www.linuxforen.de/ubb/biggrin.gif

Gruß

Robert

P.S.
Wenn du ein rm -rf Verzeichnis machst, dann wird 100%ig alles gelöscht! ;-)


[Diese Nachricht wurde von robert am 24. Januar 2000 editiert.]

25.01.00, 22:45
und wenn antimon ein dateiattribut setzt
mit chmod [options][modus][datei(liste)]
als optionen werden angeboten :
a =append der datei können nur daten ___angehängt werden sie kann weder gelöscht ___noch umbenannt werden
i =immutable eine solche datei kann nicht ___geändert werden dies schliest die ___verwaltungsinformationen mit ein auch
___links auf solch eine datei sind nicht
___möglich kann nur root setzen
s =secure beim löschen des letzten links der
___Datei werden die davon benutzten
___dateiblöche mit zufallsbytes überschrieben
___---> datei nicht wiederherstellbar

falls jemand von euch weitere attribute kennt bin ich immer daran interessiert
MfG Googol




------------------
Der Zahlen Mächtigkeit liegt in Ihrer Unendlichkeit

Hagen von Tronje
27.01.00, 02:51
Hi,

no, no, no

mit OPTIONS sind hier
-v verbose
-R rekursiv
und aehnliches gemeint !!

Das was Du meinst, sind Dateiattribute speziell
fuer das ext2-Dateisystem, und
des geht aber net mit 'chmod',
so funktioniert z. B. nicht:
chmod u+a hello.cc

Womit es funktioniert ist:
chattr +a hello.cc

Die weiteren Attibute: A, S, c, d, u
findest Du in
man chattr

http://www.linuxforen.de/ubb/wink.gif

Hagen - der bald ein online-UN!X-tutorial fuer Moderatoren und andere geben muss http://www.linuxforen.de/ubb/smile.gif

27.01.00, 19:16
oops hab ich mich doch glatt verschrieben
tschuldigung :-)
aber mit diesen dateiattributen müste das doch funzen oder?
MfG Googol

------------------
Der Zahlen Mächtigkeit liegt in Ihrer Unendlichkeit

antimon
31.01.00, 21:13
Mal ne dumme Frage:

Wie kann ich es machen, dass bei Systemstart das Skript "resetuser" automatisch ausgeführt wird??

In welche Datei muss ich es eintragen und wie??


Thx,
Antimon

robert
01.02.00, 21:27
Da gibt es zwei Möglichkeiten.

Die einfachste ist es einfach in /sbin/init.d/boot.local einzutragen.

Gruß

Robert

neodym
03.02.00, 07:45
Danke schön für die Infos.

Es klappt wunderprächtig.

Weiter so....