Hallo,

On Mon, Apr 05, 1999 at 08:27:21PM +0200, Jochen Roedenbeck wrote:
> Bei SAMBA laufen alle Verbindungen (Services) zu einem Rechner
> ueber ein- und dieselbe TCP-Verbindung und kommunzieren SAMBA-
> seitig mit derselben Inkarnation des Daemons smbd.

Das weiss ich zwar jetzt nicht ganz sicher, aber es mag sein...

> Das heiszt: Die erste (!) Verbindung, die hergestellt wird,
> bestimmt User-ID und Gruppenzuehoerigkeit des Daemons und
> damit die Zugriffsrechte auf die Dateien.

Das stimmt SO NICHT (jedenfalls nicht hier in der Firma, wo eine nicht
mehr ganz aktuelle Samba-Version Ihren Dienst tut)!

> Ich sehe hier nur eine Loesung (die bei uns verwendet wird):

Dann siehst du vermutlich nicht genug ;-)

> - Alle Nutzer werden auf dem Linux-Rechner den entsprechenden
>   Gruppen zugeordnet (hier: dta, intern, gf). Mehrfachnennungen
>   sind hier moeglich, d.h. z.b. der Geschaeftsfuehrer kommt in
>   alle drei Gruppen. (in /etc/group eintragen)
> - Die Verzeichnisse dta, intern, gf und deren Unterverzeichnisse
>   werden den jeweiligen Gruppen zugeordnet, also z.b.
>   chgrp intern /intern
>   chgrp -R intern /intern/*
>   usw.
> - Durch Setzen des Sticky-Bits kann gewaehrleistet werden, dass
>   die in den Verzeichnissen erzeugten Dateien ebenfalls der
>   entsprechenden Gruppe angehoeren. Im Prinzip genuegt es aber,
>   wenn die Hauptverzeichnisse (/dta /intern /gf) die entsprechende
>   Gruppenzugehoerigkeit haben.

Das "sticky-Bit" hat damit nicht das geringste zu tun (das wuerde auch
mit "chmod +t" gesetzt), gemeint ist hier das "SetGID" Bit. Das "sticky
Bit" wuerde bewirken, dass auch bei "public write-Rechten" jeder nur
seine eigenen Dateien loeschen darf.

>   chmod g+s /intern
>   chmod -R g+s /intern/*
>   usw.
> - Wie gemacht, werden die Zugriffsrechte auf 0770 gesetzt.

Mit gesetztem SetGID Bit waere das aber 02770, mit gesetztem sticky
Bit (statt dem SetGID Bit) 01770 ...

> Mit dieser Loesung ist es dann auch egal, ob die drei Verzeichnisse
> als getrennte Services eingerichtet werden, oder nur Unterver-
> zeichnisse in einem gemeinsamen Laufwerk werden.
> Jochen Roedenbeck

Es waere sicherlich sinnvoller, die Gruppenzugehoerigkeiten der User
passend zu regeln (genauere Hinweise siehe unten):

> (Anm: einige Hinweise habe ich noch unten zwischen den Text gesetzt)
> 
> Peter Rüffer wrote:
> > Ich will ein Linux-ISDN-Gateway ins Internet für unsere User einrichten.

Wenn ein weiterer Rechner zur Verfuegung stuende, waere es sinnvoller, das
Internetgateway gleichzeitig zum Firewall zu machen, und sonstige Funktionen
wie File-Server oder Print-Server auf einen anderen Rechner zu legen (aus
Sicherheitsgruenden)...

> > Zuallererst aber habe ich Probleme mit der Zugriffssteuerung in der
> > smb.conf. Es gibt hier eine Menge Parameter, habe schon etliche
> > probiert, aber keiner passt so richtig. :-(
> > 
> > Wir haben eine einfache 3-stufige Berechtigungshierarchie + Root:
> > 
> > 1.Alle (Standarduser)                   @alle   -> /dta, ...
> > 2.Internes (Office, Finanzen etc.)      @intern -> /dta, /intern, ...
> > 3.Geschäftsführung (Verträge etc.)      @gf     -> /dta, /intern, /gf,
> > ..

Richtig waere evt. folgende Loesung: Alle oben genannten Benutzergruppen
gehoeren zur Gruppe users (wobei diese Gruppenzugehoerigkeit nur fuer die
erste Gruppe die "primaere" Gruppenzugehoerigkeit ist). Die User aus dem
Bereich "internes" haben als primaere Gruppenzugehoerigkeit (die Gruppen-
nummer, wie sie in der /etc/passwd angegeben ist) die (evt. neu anzulegende)
Gruppe "intern", ausserdem gehoeren sie (als zweite Gruppenzugehoerigkeit)
ebenfalls zur Gruppe users (in der Datei /etc/group nachtragen), Die Ge-
schaeftsleitung gehoert zur Gruppe gf (als primaere Gruppenzugehoerigkeit)
und ist ebenfalls zu den Gruppen "intern" und "users" (oder willst du sie
wirklich dta nennen?) zugehoerig. Der "create mode" in der smb.conf wird
auf 770 gesetzt, damit kann jedes Mitglied der entsprechenden Gruppe die
jeweilige datei lesen, Dateien die von der Gescfaeftsleitung angelegt werden,
koennen auch nur von dieser Gruppe gelesen werden, Dateien, die von der 
Gruppe intern angelegt werden, koennen sowohl von dieser Gruppe als auch
von der Geschaeftsleitung, nicht aber von der Gruppe "users" (bzw. "dta",
wie auch immer du sie nennst) eingesehen werden. Dokumente dieser Gruppe
koennen sowohl von der Geschaeftsleitung als auch von der Gruppe "intern"
gelesen werden... Dabei ist es eigentlich voellig gleichgueltig, ob die
Dateien in einem einziegn share liegen oder auf 3 shares verteilt sind...

> > Die jeweils untergesordneten Stufen sollen die Verzeichnisse der höheren
> > weder sehen noch auf Dateien zugreifen können. Ich habe versucht das
> > über die Parameter "valid users", "create mode", "directory mode" zu
> > steuern, funktioniert aber nicht richtig! Sichtbar sind ALLE Services,
> > egal wie angemeldet wird, zugreifen kann man zwar nur auf die
> > berechtigten, innerhalb einer Gruppe habe ich aber dann auch noch
> > Probleme mit den Dateirechten, d.h. xyz@alle legt Verzeichnis an, dann
> > kann abc@alle zwar lesen, nicht aber ändern (create mode??).

Genau, hier hast du ein Problem mit dem "create mode", der sollte dann
fuer die Gruppe Schreibrechte vorsehen. Mit "directory mode" kannst du
dann evt. dafuer sorgen, dass Dateien nur fuer User der jeweiligen Gruppe
sichtbar sind (das habe ich aber im einzelnen nicht probiert).

> > Die smb.conf sieht derzeit so aus:
> > 
> > # /etc/smb.conf
> > [global]
> >    server string = Archiv-Server %h
> >    workgroup = KC
> >    guest account = nobody
> >    keep alive = 60
> >    os level = 2
> >    security = user
> >    printing = bsd
> >    printcap name = /etc/printcap
> >    load printers = yes
> 
> hier fehlt noch:
>      socket options = TCP_NODELAY
> sonst gibt es manchmal unerklaerliche Verbindungsabbrueche

Ist das nicht bei hinreichend neuen Samba-Versionen eine defaultmaessig
aktivierte Option, oder habe ich da etwas falsch in Erinnerung?

> > .. usw.
> > 
> > [dta]
> >    comment = Datafiles
> >    path = /dta
> >    read only = no
> >    create mode = 0775
> >    directory mode = 0775
> > 
> > [intern]
> >    comment = Internes
> >    path = /intern
> >    valid users = @intern, @gf   <- hier die notw. Gruppen!!

Ich wuerde da nur @intern hineinschreiben, und alle Mitglieder von gf
auch als Mitglieder der Gruppe intern eintragen (in /etc/group).

> >    read only = no
> >    create mode = 0770
> >    directory mode = 0770
> > 
> > [gf]
> >    comment = GF
> >    path = /gf
> >    valid users = @gf            <- dito, nur noch GF!
> >    read only = no
> >    create mode = 0770
> >    directory mode = 0770
> > 
> > .. usw.
> > 
> > Wer kann helfen? Jörg Henner hatte ein "ähnliches" Problem, die
> > Antworten haben mir aber nicht geholfen.
> > 
> > Desweiteren klappt zwar der Standard-TCP-Zugriff von einem W95-Klient
> > mit ftp.exe oder telnet.exe, aber die Verbindung kommt IMMER erst nach
> > ca. 1-2 Minuten warten zustande. Dann kann man zwar alles machen, aber
> > durch die lange Zeit funktioniert z.B. ws_ftp.exe nicht (Timeout max.
> > 120 s!) und es nervt, immer so lange auf eine Console übver Telnet
> > warten zu müssen.
> > 
> > Woran kann das wohl liegen?

Nameserver-Probleme? Am besten setzt du einen Nameserver fuer das lokale
Netz auf (klingt schwieriger als es ist), und traegst alle hosts deines
lokalen Netzes dort ein. In den Windows-Rechnern traegst du am besten ein,
dass die Namensaufloesung immer per DNS erfolgen soll und dein linux-Rech-
ner der DNS Server ist (in der DNS-Konfiguration den DNS deines Internet-
Providers als forwarder eintragen, dann sollte das auch fuer Internetzu-
griffe funktionieren).

> moeglicherweise am fehlenden DNS oder falsch konfigurierten Dateien
> C:\WINDOWS\HOSTS.

oder /etc/hosts (auf dem Linux-Rechner)... Die meisten Services laufen bei
vielen Distributionen ueber den tcpd, und der gversucht u.U. auf den resol-
ver zuzugreifen, um die Rechnernamen zu den IP-Adressen zu bekommen, von
denen eine Verbindung aufgebaut wird... Also im eigenen Nameserver auch das
"reverse-mapping" ordentlich ausetzen)...

Tschuess,
        Juergen Ilse                                    ([EMAIL PROTECTED])
-
To unsubscribe from this list please send a mail to [EMAIL PROTECTED] with
'unsubscribe suse-isdn' in its body.

Antwort per Email an