[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: samba-anmeldescripte für lehrer/schüler



Hallo Maximilian,

ich danke dir sehr dafür, dass du mir klar gemacht hast, dass ich die
"User Private Groups" offensichtlich verstanden habe. 


Maximilian Wilhelm schrieb:

> > und ich suche den Denkfehler logischerweise bei mir -
> > nur ich kann ihn nicht finden.
> 
> Bitte nimm das nicht persoenlich, aber das mag vielleicht an Deiner
> Windowssicht der Dinge liegen.

auch dann würde es mir weiterhelfen, wenn ich die Stelle erkenne, die dieses
besondere Augenmerk erfordert.
 
> [...]
> > bedeutet das, dass jeder User ein Projektverzeichnis erstellen kann und
> > dieser User kann dann sagen, wer in diesem Verzeichnis schalten und walten
> > kann? - für einen Server an einer Uni, einer Firma, einer Community ist das
> > voll okay, aber für eine Schule? mir sträuben sich als Admin die Nackenhaare
> > wenn es denn so wäre :-(
> 
> Das haengt ganz davon ab, *wo* er das Verzeichnis anlegen soll/kann/darf.
> In seinem $HOME kann der User natuerlich machen was er will, und das ist
> auch gut so; alles andere wuerde private Homes ad absurdum fuehren.

Hier gebe ich Helmut recht.

> 
> Mir schwebt eher ein /skole/tjener/projekte/<foo> vor (um mal in der
> akt. Nameskonvention zu bleiben) vor, wo der *Admin* ein Projektverzeichnis
> anlegt und automagisch die Rechte korrekt gesetzt werden. (owner =
> $Lehrer, Gruppe=$Projektgruppe)

wir hatten damals 2 Fälle spezifiziert:
der Admin (er hat eh die Verantwortung) kann natürlich die Projektgruppen
anlegen ...
und der Admin kann diese Aufgabe delegieren, d.h. er kann einen Lehrer
das Recht geben, neue Gruppen einzurichten, für die _dieser_ Lehrer dann
verantwortlich ist.

nach meinen Kenntnis- und Wissenstand (ich bin nur popeliger Lehrer) braucht
man dafür KEINE "User Private Groups". 


> In seinem $HOME kann er natuerlich beliebig Verzeichnisse anlegen,
> die Rechte dafuer aendern (chmod 2775 <dir>) und eine Gruppe festlegen,
> die dort wurschteln darf (chgrp students <dir>).
 
und das kann nicht im Interesse der Schule sein. Und das ermöglichen m.E.
die "User Private Groups". Deshalb stehe ich (momentan) noch auf dem 
Standpunkt, die sind für einen Schulserver einfach fehl am Platz (oder 
sollten zumindestens "abschaltbar" sein)



> [...]
> > das ist schon richtig. Aber es gibt Vorteile und Nachteile und es gibt
> > K.o.-Kriterien. Wenn jeder User ein Verzeichnis mit verbotenen bzw.
> > unerwünschten Inhalten anlegen kann und kann dieses Verzeichnis jeglicher
> > Kontrolle von Lehrern (z.B. während des Unterrichts) entziehen, dann ist
> > es nur eine Frage der Zeit, bis eine Neuauflage von Erfurt (Gutenberg-
> > Gymnasium) ins Haus steht.
> 
> Natuerlich kann ein User ein Verzeichnis anlegen und den Lehrer erstmal
> aussperren.
> mkdir ganzBoeseSachen
> chmod 700 ganzBoeseSachen
> chgrp lehrer ganzBoeseSachen
> 
> Das geht aber auch bei Arktur mit seinen Windows-Clients und Samba...

Es ging bisher nicht. Es geht erst mit Windows-clients ab Win2000 und mit
Linux-Clients. Mit den in der Hauptsache bisher zum Einsatz gekommenen
Win98-Clients ging es definitiv nicht. Ich gebe dir recht, dass das noch 
nicht neu überdacht ist. 

> Un nu?

muss m.E. bei Arktur dafür gesorgt werden, dass die Lehrer (für den Fall der
Fälle) auf alle Dateien Leserecht erhalten können. so auf die Schnelle sehe
ich die Lösung über eine ACL-default-Regel, die ja vererbt wird. Ich 
überblicke momentan nicht, wie man mit vertretbaren Aufwand dafür sorgen kann, 
dass der Eigentümer diese ACL nicht einfach rückgängig machen kann. Aber 
lösbar ist das allemal. 

Noch ein Bemerkung wegen den Windows-clients. die reichen die ACL nur durch.
Auch hier gilt, alles was ich geschrieben habe gilt ebenso für Linux-clients.

 
> > Ob Counterstrike nun wirklich die Ursache des
> > Unheils ist, steht für den betroffenen Admin gar nicht zur Debatte.
> > Ihm wird man grobe Fahrlässigkeit vorwerfen, ein System installiert zu
> > haben, welches nicht ermöglicht, dass die Lehrer ihrer Verantwortung
> > insbesondere gegenüber jüngeren "Schutzbefohlenen" gerecht werden konnten.
> 
> *gaehn*

Anforderungen von Lehrern an einen Schulserver sind langweilig. das wurde 
allerdings schon viel schärfer in einem Protokoll ausgedrückt:

<zitat> 
  daß das Pflichtenheft "eine Aneinanderreihung _ermüdender_ Details" ist, ...
  Die Anwesenden stimmten ... zu; 
</zitat>

> Bitte ein bisschen Realismus.

du kennst das Wiki von Skolelinux wohl nicht? die Auflistung von Vorfällen
was alles passiert ist (nicht sein könnte!), stammt von mir. Es gab KEINE
Ergänzung, nur "kluge" Kommentare, was ich alles falsch gemacht habe und
was diese Kommentierer demzufolge alles richtig machen.

Ich sehe das so, es gibt kaum einer zu, was alles passiert, vorausgesetzt
er bekommt es überhaupt mit. Aber wenn man dafür sorgt (z.B. mit
"User Private Groups") dass man nichts mehr mitbekommen kann, dann kann man
natürlich seinen Schnabel weit aufreisen, dass bei dem nichts passiert und
die andern einfach unfähig sind. 


> Ich habe auch schon oft CounterStrike und aehnliches gespielt, laufe
> jetzt aber auch nicht mit ner Knarre durch die Uni und schiesse auf
> alles, was sich bewegt...

darum geht es nicht. Es geht darum, dass jemand die Verantwortung tragen
muss und das ist der, der das System installiert hat. aus dessen Sicht sollte
man versuchen, das Problem zu sehen. 
 
> Wenn Leute das spielen wollen, dann lasst sie das tun.
> Wenn Ihr Angst habt, dass sie das in der Schule tun, dann sagt ihnen
> einfach, dass sie CS bitte zu Hause spielen sollen und sie erst garnicht
> auf die Idee kommen sollen, sowas in der Schule zu speichern, geschweige
> denn zu spielen.
> Mal ehrlich: Wann sollen die Schueler eigentlich Zeit haben, CS und
> Konsorten zu spielen? Im Unterricht? Dann macht der Lehrer etwas sehr
> drastisch falsch!

bitte: darum geht es doch gar nicht. in unserem Internet-Cafe wird natürlich
in der Mehrzahl der Fälle gespielt, obwohl es nicht dafür eingerichtet wurde.
Es erfüllt auch seinen Zweck, wenn schüler die es für Hausaufgaben bzw.
projekte nutzen wollen auch nutzen können. (und das ist gewährleistet).
Und solange wie nichts passiert (was auch immer das sein möge) wird es auch
kein Problem geben. Aber wenn die Schüler sich CDs zusammenstellen mit
Raubkopien und machen das in Verzeichnissen, wo man vorher die Lehrer raus-
schmeissen konnte, dann ist das Problem da. die Lehrer können sich nicht
rausreden, sie wußten von nichts, denn sie haben das zugelassen, das sie
dann wie die begossenen Pudel dastehen. Ich finde die Lösung einfach nicht 
gut für einen Schulserver .

  :

> Ein User kann *immer* Daten verstecken, ob er dazu eine private Gruppe
> hat spiel dabei ueberhauptkeine Rolle...

Aber der Lehrer darf denen das Handwerkszeug für solche Machenschaften nicht
noch bereitstellen. 
bitte den Vergleich nicht übelnehmen: bei Arktur hat er ein Homeverzeichnis,
es gibt ein Tauschverzeichnis (und das wird bei uns regelmäßig gelöscht) und
es hat jeder Zugriff und es gibt Projektgruppen und da gibt es einen 
Verantwortlichen (meistens ein Lehrer). Also keine Gruppen ohne Kontrolle
(-möglichkeit).


> Und wenn er das Zeug in /tmp oder /dev/shm oder wasweissichwo versteckt...
> Solange er da schreiben darf ist das fuerchterlich egal.

nochmal, er kann natürlich in seinem Homeverzeichnis schreiben, aber er kann
(bzw. darf) nicht dort ein solches Projekt für eine Gruppe ohne Kontroll-
möglichkeit anlegen können.

> 
> Das kann er ueberigens auch in Deinem $HOME als
> .ganzGanzBoeseDinge/nochVielBoeser/... machen, wenn er da dran darf...

nein, ein Schüler kommt bei Arktur niemals in das Homeverzeichnis eines 
anderen Schüler oder gar Lehrer, es sei denn, es wurde für ihn extra 
freigegeben (mit einer ACL). Es ist ein persönliches Homeverzeichnis!

 
> > mir geht es nicht um Windows. die Überlegungen gelten für Linux-, Windows-
> > Mac-Clients gleichermaßen.
> 
> Hmm, ich lese bei Dir immer wieder "samba".

das liegt daran, dass ich von dem schreibe was ich kenne. mir ist allerdings 
bewußt, ob bestimmte Sachen nur mit Samba gehen oder nicht. Zugriffsrechte und
ACLs sind auf einer Stufe tiefer, sodass die für Linux-clients gleichermaßen
gelten. Nur ich kann nicht mit diesen Begriffen um mich werfen, weil ich mich
damit nicht auskenne.

> Was ist mit NFS/AFS/whatever und Linux/Unix?
> 
> > verständlich schon. m.E. habe ich den Sinn dieser "User Private Groups" bei
> > einem Debian-Server verstanden. Aber für einen Schulserver sehe ich momentan
> > nur Nachteile.
> 
> Die da waeren?

- Bereiche die dem Verantwortungsbereich von Lehrern entzogen werden können.
- Probleme bei der Nutzung der Parameter bei netlogon


> 
> > - ich habe es demnach immernoch nicht gerafft. :-(
> 
> Vergiss mal alles, was Du bisher fuer Arktur entwickelt und eingesetzt hast.
> Dann vergiss mal Windows und ACLs. (Eine Diskussion ueber "(Skole)Linux kann
> keine ACLs" ist mueszig... AFS kommt... hoffentlich bald...)

ich habe nicht über Skolelinux gesprochen und schon gar nicht versucht Skole-
linux zu werten. Das steht mir nicht zu. Mir ging es um das Problem, was sind
"User Private Groups" (ich denke ich habe die Philosophie verstanden) und was
bedeutet das, wenn diese bei einem Schulserver eingesetzt werden. Hier sehe
ich ein ernstliches Problem ("Wegdrücken der Lehrer") und einen Nachteil
(Gruppenparameter bei netlogon läßt sich nicht nutzen). Den Vorteil der diese
Nachteile aufwiegt kann ich für einen _Schulserver_ immernoch nicht erkennen.

 
> Jetzt stell Dir mal einen Rechner mit Linux vor (von mir aus auch ein
> paar mehr, die vernetzt sind und auf den gleichen Datenbestand zugreifen)
> und ueberleg Dir, wie Du *da* Zugriffsrechte setzten willst um
> Kooperationen zu ermoeglichen und was Du dafuer alles brauchst...
> (Gruppen, SGID-Bit...)

das brauche ich nicht zu überlegen, eine funktionierende Projektverwaltung
hat Arktur schon seit Jahren. Allerdings nicht so wie im Pflichtenheft 
beschrieben. Das habe ich mir wirklich als Programierobjekt vorgenommen ;-)



                                  /"\
Mit freundlichen Grüßen           \ / ASCII ribbon campaign
Hans-Dietrich                      X  against HTML mail 
                                  / \ and postings



Reply to: