[gelöst] guest ok = yes geht nicht

Hallo,

ich habe folgendes Problem:
ein Server (opensuse 10.2) mit einigen Freigaben, teilweise mit "guest ok = yes" einige mit "no"

Greife ich von einem suse client (opensuse 11.1) mit Konqueror oder Dolphin darauf zu ist alles ok. D.h. bei den Freigaben mit "guest ok =no", werde ich nach credentials gefragt. Bei den anderen nicht.

Versuche ich es auf der Kommandozeile, dann funktioniert die guest Option nicht:

Irgendjemand 'ne Idee wo mein Denkfehler liegt?

mus das nicht -o username=guest,password=geheim heißen

eigentlich ist die Doku da eindeutig.


Da es aber nicht der erste Fehler wäre kann ich das ja mal ausprobieren.
Aber falls das geht kann es dann ja auch an der option "map to guest = bad user" liegen

also mit geht es insofern, als dass ich dann zwar nach dem Passwort gefragt werde aber keines eingeben muss. Eingabetaste reicht.
Das ist aber nur wegen dem map to guest der Fall. Check: es geht auch mit "gust" statt "guest" und jedem anderen unbekannten Usernamen.
Bei der Option "guest" (nicht dem usernamen guest) sollte er aber gar nicht nach dem Passwort fragen.

Hab' grad noch was probiert:
geht. Ich vermute dass es daran liegt, dass es den lokalen user, zufällig auch auf dem Server gibt. Dieser username wird default-mäßig verwendet und dann will er natürlich auch ein Passwort. Die Passwortabfrage zu deaktivieren mittels der guest-option geht dann nicht.

Ich könnte das jetzt prüfen indem ich mal die map to guest option deaktiviere, will aber gerade nicht am Server rumbasteln, weil sonst der WAF kritisch abfällt

Wenn man kein Passwort braucht, heißt das noch lange nicht das man kein Passwort braucht, sondern das das Passwort das NULL-Passwort ist. Hat das irgend jemand verstanden?

• 
  mount -t cifs //server/public /mnt -o username=guest,password=""

Wenn man kein Passwort braucht, heißt das noch lange nicht das man kein Passwort braucht, sondern das das Passwort das NULL-Passwort ist. Hat das irgend jemand verstanden?

Zum Vergrößern anklicken....

... und wenn man es mal verstanden hat, dann merkt man schnell das die option "guest" nichts anderes tut als "password="", also überflüssig

Und beides funtioniert auch nur wennn man explizit einen usernamen mit ohne Passwort auswählt oder einen unbekannten im Zusammenspiel mit "Map to guest = bad user"

@Tooltime: ist der user "guest" ein "Spezialfall", oder würde Dein Kommando
den Bach runtergehen wenn man einen User mit Namen "guest" anlegt und mit Passwort ausstattet?

Anyway, ich denke ich setz das damit mal auf gelöst

Vorab hier die gekürzte Version meiner smb.conf:

• [global]
  workgroup = Zuhause
  map to guest = Bad User
  usershare allow guests = Yes
  security = user
  
  [public]
  comment = Ein freies Verzeichnis
  inherit acls = Yes
  path = /srv/public/
  read only = No
  guest ok = Yes

1. Die Passwortabfrage kommt vom Mount-Befehl, er achtet darauf das er die richtige Anzahl an Parametern bekommt. Wird kein Passwort in den Mount-Optionen definiert, ist dem Befehl klar das er nachfragen muss. Ich gebe zu das ich das mit meinen Passwortgequatsche nicht richtig herüber gebracht habe, dachte allerdings das wäre offensichtlich.

2. Dem cifs-Server ist beim guest-Account das Passwort egal. Aus Formatgründen muss es wahrscheinlich in den Credentials vorhanden sein, der Inhalt ist aber nicht von Bedeutung. Also auch ein leeres Passwortfeld wird akzeptiert. Wahrscheinlich hätte password="0x1769h#@25" viel cooler ausgesehen, hat aber den gleichen Effekt wie password="beliebig" oder halt password="".

3. "map to guest = Bad User" bedeutet, jeder nicht bekannte Benutzername wird automatisch zu guest und muss sich nicht extra als guest einloggen. Daher zeigen deine Variationen vom Benutzer guest, das gleiche Verhalten wie eine Anmeldung mit dem Original. Deshalb funktioniert auch so etwas wie,

• mount -t cifs //server/public /mnt -o username=mr_unbekannt,password="0x1769h#@25"

4. Der Parameter uid definiert ein Mapping des cifs-account auf das lokale Sytem.

• mount -t cifs //server/public /mnt -o uid=nobody,username=guest,password=""

Der cifs-User guest erhält die USER-ID des lokalen Unix-User nobody.

5. Wenn ich deinen ursprünglichen Befehl analog umsetze

• mount -t cifs //server/public /mnt -o guest

erhalte ich natürlich exakt die gleiche Fehlermeldung. Der Befehl mount kennt halt keine Option die guest heißt.

6.

pft schrieb:

@Tooltime: ist der user "guest" ein "Spezialfall", oder würde Dein Kommando
CODE: ALLES AUSWÄHLEN
mount -t cifs //server/public /mnt -o username=guest,password=""

den Bach runtergehen wenn man einen User mit Namen "guest" anlegt und mit Passwort ausstattet?

Zum Vergrößern anklicken....

Natürlich habe ich keinen Benutzer mit einer reservierten System-ID angelegt. Daher hat guest weder einen Eintrag in der smbpasswd, noch ein definiertes Passwort. Und was passiert wenn so einen User definiert wird interressiert mich auch nicht. Ich ändere unter Linux den User nobody auch nicht in unknown und lege dann einen regulären Benutzer mit dem Namen nobody an. Da kann sicherheitstechnisch doch nur Unfug bei raus kommen.

Ist ja schon gut ;-)

Ich dachte halt nur, wenn man schon eine Option "guest" implementiert (eben nicht username = guest) dann ist doch logisch dass dazu zwei Dinge gehören: den user auf guest setzen muss und die Passwortabfrage abschalten. Man hätte also beides implizit tun können und nicht nur den zweiten Teil :-(