proftpd mod_auth_file und ordnerberechtigungen

[stunner]

erstmal hallo!

ich bin gerade dabei, den proftpd server auf einem mac os x rechner aufzusetzen.
der server selbst läuft als nobody.
die benutzer-authentifizierung läuft über eine mit ftpasswd angelegte benutzer-datei und dem modul mod_auth_file.
hier gibt es einen benutzer 'gast', der ein kennwort hat. dieser ist kein systembenutzer und soll es auch nicht sein.
sein home-verzeichnis ist /ftp.
besitzer dieses verzeichnisses ist momentan nobody.
setze ich die berechtigungen auf 770, bekommt der 'gast' diesen ordner aber gar nicht zu gesicht ("login failed" ->

"unable to chdir to / (Permission denied), defaulting to chroot directory /ftp"
"gast chdir("/"): Permission denied"

)

um diesen ordner sehen, öffnen sowie darin lesen und schreiben zu können, muss ich die berechtigungen für 'alle' auf rwx setzen. das verstehe ich nicht, da eine von 'gast' neu angelegte datei ja auch nobody gehört...
könnte mir das jemand erklären? wer soll denn benutzer der datei sein? root oder admin geht auch nicht....

vielen dank und gruß
stunner

[VolGas]

Hallo!

Ich arbeite auch mit OS X, allerdings ohne ProFTPD darauf - das muß nur auf unseren Linux-Servern laufen.
Das auf dem Mac aber im "Untergrund" auch ein Unix läuft, kommt auf das Gleiche heraus.

Mit dem Unix-Rechtesystem scheinst Du ein paar generelle Verständnisporbleme zu haben.
Ich versuche es kurz zu fassen, denn hier ist eingentlich nicht das Medium, um prinzipielle
Unixprobleme zu erklären - das wird im Internet taußendfach angeboten.

Du mußt Dir vorstellen, daß das Filesystem jeder Datei eine User-ID und eine Gruppen-ID (UID/GID)
zuweist. Dabei ist es dem Filesystem völlig schnuppe, ob zu den jeweiligen ID's ein User / eine Gruppe
im System eingetragen ist. Dabei wird den ID's nur ein Name (und div. andere Dinge) zugewiesen -
also für das Filesystem unerheblich. Nur daher ist es möglich, auch mit virtuellen Usern zu arbeiten:
in Deinem Fall "mod_auth_file".

Den ProFTPD mußt Du wie eine Benutzershell sehen: nach dem Einloggen hat er die selbe UID/GID
wie der angemeldete User und damit auch dessen Rechte und Beschränkungen.

Es gibt zwar einen User "nobody", aber der ist auch nur ein ganz normaler Systemuser und keine
"Sonderkonstruktion", die alles abfängt. (UID: 65534 bzw. -2)

Vielleicht kannst Du nun so langsam nachvollziehen, weshalb Dein Benutzer "gast" nur deshalb
eine Chanche hatte, wenn Du das/die Verzeichnis(se) world-readable gesetzt hattest. Damit der
User in dem Verzeichnis "schalten & walten" kann wie er möchte, muß er Eigentümer oder
zumindest in einer berechtigten Gruppe sein.

Eine gemeinsame Gruppe wird sowieso notwendig sein, wenn Du später auf dessen Dateien
ebenfalls Zugriff haben möchtest...

Ich hoffe, ich konnte Dir ein Stück weiterhelfen.

mfg.
  VolGas

[stunner]

hallo,

vielen dank für die ausführliche antwort.
ich dachte bisher, mit dem unix rechtesystem an sich käme ich einigermassen klar

allerdings nicht so ganz mit den virtuellen benutzern.
wenn mein virtueller benutzer 'gast' einen ordner in seinem ftp-verzeichnis anlegt, wird mir als besitzer dieses ordners nobody angezeigt, unter dem auch der ftp-server läuft. daraus schloss ich, dass er dann auch die UID des nobody und nicht die des gastes hat.
falsch geschlussfolgert?

dank und gruß
stunner

[VolGas]

Nein, richtig - und vielleicht auch gleichzeitig falsch...

Man kann bei den virtuellen Auth-Methoden ja jedem User beliebig eine UID/GID zuteilen.
In Deinem Fall hast Du wohl dem virtuellen User "gast" die selbe UID wie dem Systemuser
"nobody" zugeteilt. Das kann aber auch ganz von Deiner Konfiguration abhängen, dazu
müßte ich einmal Deine proftpd.conf sehen - vielleicht postest Du diese einfach einmal hier.

mfg.
  VolGas

[stunner]

hallo
so, bin wieder einen schritt weiter.
erstmal sorry, hatte gestern nachmittag wohl einen knick inner pupille und gestern abend den rechner nicht vor mir. neu angelegte ordner und dateien gehören tatsächlich dem virtuellen benutzer. allerdings der gruppe des übergeordneten ordners und nicht seiner primärgruppe.
das hat allerdings was mit macosx zu tun.  warum das so ist, kann ich nicht rausfinden (kein s-bit gesetzt), ist aber auch nicht thema dieses forums...

schönen dank für die hilfe
gruß
stunner