[proftpd] Users chrooten in hun home directory + project dir

[Maxonic]

Voor een project heb ik een Proftpd server opgezet. Nu hebben alle gebruikers hun eigen home dir /home/<username>. Als ze ingelogd zijn, zijn ze vastgezet in deze directory.
Er is echter ook een algemene documentroot die alle gebruikers moeten delen. Deze bevind zich op /var/www/localhost/. In de homedirs van de gebruikers heb ik met 'ln' een link naar deze map gemaakt. Als de gebruikers met SSH inloggen zien ze deze link en kunnen ze zo bij de gedeelde webspace komen.
Echter als de gebruikers met FTP inloggen zien ze deze link niet en kunnen ze alleen in hun eigen homedir met public_html komen. Hoe stel ik het nu zo in dat de gebruikers dus in hun homedir vastzitten maar wel de link kunnen volgen naar de gedeelde webspace?

Op de site van ProFTPD valt hier niks over te lezen. Momenteel heb ik in mijn configfile gewoon "DefaultRoot ~" staan.

[majornono]

welke versie van proftpd heb je en wat staat er in de proftpd.conf?

Er is een optie genaamd "ShowSymlinks". Als die op off staat, (default voor versies onder 1.1.5) kun je links niet zien.

[_Squatt_]

Als je DefaultRoot gebruikt dan gebruikt proftpd een chroot() call, en kunnen gebruikers niet buiten hun root komen (tenzij ze die chroot weten te omzeilen, dan heb je echter grotere problemen).

Je zou /var/ww/localhost voor elke users kunnen 'mount --bind'-en maar dat is zo'n lelijke oplossing dat ik mijn handen moet wassen na dat getikt te hebben.

Kunnen ze niet gewoon ssh/sftp gebruiken? Anders is het misschien een idee om er WebDAV mappen van te maken.

[ Voor 6% gewijzigd door _Squatt_ op 17-08-2004 15:48 ]

[majornono]

squatt heeft natuurlijk gelijk. Die optie van mij werkt alleen binnen een chroot omgeving natuurlijk

Misschien een oplossing om de www directory te verplaatsen naar dezelfde map als de user directories en ze daarin te houden met defaultroot. Door de rechten te zetten kunnen ze dan alleen hun eigen dir in & de algemene map.
Deze oplossing heb ik zelf ook.

[blaataaps]

Als je niet gebonden bent aan proftpd kun je pure-ftpd gebruiken, als je die met virtual-chroot support compilet, kun je wel symlinks buiten de eerste chroot volgen.

[Maxonic]

Ik ben helaas wel aan ProFTPD gebonden. Maar het zou toch raar zijn als ProFTPD geen ondersteuning bied voor deze situatie. Het zal toch wel vaker voorkomen.

Je zou /var/ww/localhost voor elke users kunnen 'mount --bind'-en maar dat is zo'n lelijke oplossing dat ik mijn handen moet wassen na dat getikt te hebben.

Ja, inderdaad. Ik ga ook mijn ogen uitspoelen na dit gelezen te hebben.

Misschien een oplossing om de www directory te verplaatsen naar dezelfde map als de user directories en ze daarin te houden met defaultroot. Door de rechten te zetten kunnen ze dan alleen hun eigen dir in & de algemene map.
Deze oplossing heb ik zelf ook.

Zou ik misschien mogen zien hou je dat in je config hebt staan?

Ik maak gebruik van ProFTPD Version 1.2.9
Mijn config op het moment:

code:

ServerName          "LSVB-Som Ftp Server"
ServerType          standalone
DefaultServer           on
Port                21
Umask               022
MaxInstances            30
User                nobody
Group               nogroup
DefaultRoot ~

<Directory />
  AllowOverwrite        on
</Directory>

[majornono]

In je proftpd.conf de default root aanpassen in het volgende:

code:

DefaultRoot             /home

vervolgens de dir /var/ww/localhost verplaatsen naar /home/localhost.

Met rechten ervoor zorgen (indien nodig) dat users niet in elkaars mappen gaan klooien en wel in de localhost dir.

[V-2]

Andere optie is, als beide dirs op hetzelfde filesystem staan, in elke homedir een hard link aanmaken naar de webroot ... maar dat is ook niet echt elegant.

[_Squatt_]

Hard links werken niet voor directories.

[V-2]

man ln zegt:

code:

GNU OPTIONS
       -d, -F, --directory
              Allow the super-user to make hard links to directories.

Kan wel dus. Maar er zit wel een klein risico aan, als je een recursieve hard link maakt dan heb je een behoorlijk probleem. Moet je met low-level filesystem tools inodes gaan clearen enzo niet zo cool.