Verzeichnisse löschen auf Samba-Share

Markus Hoppe

19 Jun 2003 19 Jun '03

11:48

Hallo Listenbewohner Ich habe ein seltsames Samba-Problem, von dem ich nicht genau weis, ob es auf der Server- oder der Clientseite zu suchen ist. Ich tippe fast auf einen Fehler in KDE. Folgende Situation: Samba-Server 2.2.8a auf SuSe 7.3 /etc/samba/smb.conf (nur die vermeintlich relevanten Stellen) (Schnipp) [global] security = user encrypt passwords = yes guest ok = no guest account = nobody map to guest = never [share] comment = Volume1 auf %h path = /hda6/share writeable = yes directory mode = 770 create mode = 660 (Schnapp) Meine Clients: mehrere Win98, Win2k und ein Linux (Mandrake 9.1) Auf allen Windows-Clients kann ich auf share schreiben, lesen, löschen ohne irgendwelche Einschränkungen und so soll es auch sein. Auf dem Linux-Client kann ich auf der Konsole oder im Midnight Commander ebenfalls schreiben, lesen und löschen, ohne irgendwelche Einschränkungen. Nur im KDE-Dateimanager Konqueror kann ich auf dem share keine Verzeichnisse löschen. Sonst geht alles: Dateien anlegen, ändern, löschen und umbenennen sowie Verzeichnisse anlegen und umbenennen. Nur das löschen von Verzeichnissen geht nicht. KDE-Konqui - rechte Maustaste - Neu erstellen - Verzeichnis: geht. Dann rechte Maustaste auf das eben erstellte Verzeichnis - Löschen bringt mir die Fehlermeldung "Verzeichnis ließ sich nicht löschen..." Gemountet habe ich das share am Client aus der fstab mit: //server/share /mnt/share smbfs / credentials=/ziel/der/passwortdatei / ,uid=markus,gid=users,fmask=0660,dmask=0777, / workgroup=WORKGROUP,user,quiet,iocharset=iso8859-15 / ,codepage=437 0 0 ...und bin auch als markus angemeldet. Sollte doch eigentlich gehen, oder ? Wie schon gesagt, auf dem selben Linux-Client auf der Konsole bzw. mc kann ich auch Verzeichnisse löschen ?! Hat da einer von euch ne Idee, wo ich noch drann schrauben kann?

Show replies by date

Robert Szentmihalyi

19 Jun 19 Jun

12:28

On Thursday 19 June 2003 13:48, Markus Hoppe wrote:

...

Hallo Listenbewohner

Ich habe ein seltsames Samba-Problem, von dem ich nicht genau weis, ob es auf der Server- oder der Clientseite zu suchen ist. Ich tippe fast auf einen Fehler in KDE. Folgende Situation:

[...]

...

Meine Clients: mehrere Win98, Win2k und ein Linux (Mandrake 9.1)

Auf allen Windows-Clients kann ich auf share schreiben, lesen, löschen ohne irgendwelche Einschränkungen und so soll es auch sein.

Auf dem Linux-Client kann ich auf der Konsole oder im Midnight Commander ebenfalls schreiben, lesen und löschen, ohne irgendwelche Einschränkungen.

Nur im KDE-Dateimanager Konqueror kann ich auf dem share keine Verzeichnisse löschen. Sonst geht alles: Dateien anlegen, ändern, löschen und umbenennen sowie Verzeichnisse anlegen und umbenennen. Nur das löschen von Verzeichnissen geht nicht. KDE-Konqui - rechte Maustaste - Neu erstellen - Verzeichnis: geht. Dann rechte Maustaste auf das eben erstellte Verzeichnis - Löschen bringt mir die Fehlermeldung "Verzeichnis ließ sich nicht löschen..."

[ ... ]

...

Sollte doch eigentlich gehen, oder ?

Wie schon gesagt, auf dem selben Linux-Client auf der Konsole bzw. mc kann ich auch Verzeichnisse löschen ?!

Hat da einer von euch ne Idee, wo ich noch drann schrauben kann?

Sieht nach einem KDE Problem aus. Sehr merkwürdig... Welche KDE Version? Mich wundert allerdings, warum du nicht über NFS auf den Server zugreifst. Wäre ohnehin die sauberere Lösung. Gruss, Robert -- Robert Szentmihalyi, Entracom GmbH Enter and start communication. - http://www.entracom.de solidBITS - The Server On CD Solution - http://www.solidbits.com

Markus Hoppe

13:52

Am Donnerstag, 19. Juni 2003 14:28 schrieb Robert Szentmihalyi:

...

On Thursday 19 June 2003 13:48, Markus Hoppe wrote: [...] Sieht nach einem KDE Problem aus. Sehr merkwürdig... Welche KDE Version? KDE 3.1.0, Mandrake 9.1

...

Mich wundert allerdings, warum du nicht über NFS auf den Server zugreifst. Wäre ohnehin die sauberere Lösung. Stimmt schon, aber der Server hängt am Netz und ich will aus Sicherheitsgründen nur die Dienste laufen lassen, die ich unbedingt brauche. Und weil er hauptsächlich die Windosen bedienen soll, komme ich um Samba nicht herum.

Gruß Markus

Robert Szentmihalyi

14:16

On Thursday 19 June 2003 15:52, Markus Hoppe wrote:

...

Am Donnerstag, 19. Juni 2003 14:28 schrieb Robert Szentmihalyi:

...
On Thursday 19 June 2003 13:48, Markus Hoppe wrote: [...] Sieht nach einem KDE Problem aus. Sehr merkwürdig... Welche KDE Version?

KDE 3.1.0, Mandrake 9.1

Würde ich mal updaten. KDE 3.1.0 hat ein paar hässliche Bugs.

...

...
Mich wundert allerdings, warum du nicht über NFS auf den Server zugreifst. Wäre ohnehin die sauberere Lösung.

Stimmt schon, aber der Server hängt am Netz und ich will aus Sicherheitsgründen nur die Dienste laufen lassen, die ich unbedingt brauche. Und weil er hauptsächlich die Windosen bedienen soll, komme ich um Samba nicht herum.

Schlechtes Argument. Wenn der Samba Server ohne Firewall direkt am Netz hängt, hast Du sowieso grundlegende Security Probleme (kann nich dir bei Bedarf gerne zeigen). Mit Firewall macht es keinen Unterschied, ob NFS zusätzlich läuft oder nicht, da die Dienste sowieso nur aus dem Intranet erreichbar sind, wenn die Firewall vernünftig konfiguriert ist.

...

Gruß Markus

Gruss, Robert -- Robert Szentmihalyi, Entracom GmbH Enter and start communication. - http://www.entracom.de solidBITS - The Server On CD Solution - http://www.solidbits.com

Markus Hoppe

16:40

Am Donnerstag, 19. Juni 2003 16:16 schrieb Robert Szentmihalyi:

...

On Thursday 19 June 2003 15:52, Markus Hoppe wrote:

...
Am Donnerstag, 19. Juni 2003 14:28 schrieb Robert Szentmihalyi:

...
On Thursday 19 June 2003 13:48, Markus Hoppe wrote: [...] Sieht nach einem KDE Problem aus. Sehr merkwürdig... Welche KDE Version?

KDE 3.1.0, Mandrake 9.1

Würde ich mal updaten. KDE 3.1.0 hat ein paar hässliche Bugs. Das war es. Ich habe eben ein Onlineupdate gemacht. Keine KDE-Pakete, aber unter anderem (verdächtig) die qt auf qt-3.1.1.13.1mdk aktualisiert. Darüber hinaus nochmal ein paar unnötige Dienste auf dem Client rausgeschmissen, neustart und siehe da - ich kann jetzt auch Verzeichnisse löschen. Woran es jetzt letztlich genau gelegen hat weis ich zwar leider nicht, vermute aber, wie oben schon erwähnt, die qt.

Danke Robert Gruß Markus.

Joachim Kieferle

21:09

Robert Szentmihalyi wrote:

...

[ ... ]

...
Stimmt schon, aber der Server hängt am Netz und ich will aus Sicherheitsgründen nur die Dienste laufen lassen, die ich unbedingt brauche. Und weil er hauptsächlich die Windosen bedienen soll, komme ich um Samba nicht herum.

Schlechtes Argument. Wenn der Samba Server ohne Firewall direkt am Netz hängt, hast Du sowieso grundlegende Security Probleme (kann nich dir bei Bedarf gerne zeigen). Mit Firewall macht es keinen Unterschied, ob NFS zusätzlich läuft oder nicht, da die Dienste sowieso nur aus dem Intranet erreichbar sind, wenn die Firewall vernünftig konfiguriert ist.

Hallo Robert, kannst Du zu den "Security Problemen" bitte etwas genaueres sagen? Wie sieht's aus, wenn man in der smb.conf explizit nur die eigene IP-Range freigibt? Wäre sicher für die eine / den anderen interessant, die einen öffentlich zugänglichen Server (und sei's nur über dyndns o.ä. ) am Laufen haben. Viele Grüsse Joachim

Robert Szentmihalyi

20 Jun 20 Jun

09:42

On Thursday 19 June 2003 23:09, Joachim Kieferle wrote:

...

Robert Szentmihalyi wrote:

...
[ ... ]

...
Stimmt schon, aber der Server hängt am Netz und ich will aus Sicherheitsgründen nur die Dienste laufen lassen, die ich unbedingt brauche. Und weil er hauptsächlich die Windosen bedienen soll, komme ich um Samba nicht herum.

Schlechtes Argument. Wenn der Samba Server ohne Firewall direkt am Netz hängt, hast Du sowieso grundlegende Security Probleme (kann nich dir bei Bedarf gerne zeigen). Mit Firewall macht es keinen Unterschied, ob NFS zusätzlich läuft oder nicht, da die Dienste sowieso nur aus dem Intranet erreichbar sind, wenn die Firewall vernünftig konfiguriert ist.

Hallo Robert,

kannst Du zu den "Security Problemen" bitte etwas genaueres sagen? Wie sieht's aus, wenn man in der smb.conf explizit nur die eigene IP-Range freigibt?

Das sollte man sowieso tun. Das ist aber ein schwacher Schutz, denn er verhindert nur, dass SMB requests auf anderen als dem angegebenen interfaces beantwortet werden, zumindest nicht, solange der Angreifer keine Lücke in Samba findet (setzt unter anderem vorraus dass du immer die aktuelle Version am Laufen hast, was bei den meisten nicht der Fall ist), denn die Ports sind ja ohne Firewall immer noch offen. Das ist aber ohnehin der unwahrscheinlichere Fall. Wahrscheinlicher ist, dass der Angreifer über eine andere Sicherheitslücke in dein System eindringt, und wenn der Server ohne Firewall direkt am Internet hängt hat er dann direkten Zugriff auf das Dateisystem des Rechner auf dem sich deine ganzen Daten befinden. Solltest du einen solchen Server am Netz haben, lass halt mal Nessus drüber laufen und lass dich überraschen :-)

...

Wäre sicher für die eine / den anderen interessant, die einen öffentlich zugänglichen Server (und sei's nur über dyndns o.ä. ) am Laufen haben.

Dyndns ist grundsätzlich gefährlich und ohne Firewall würde ich das sowieso nicht machen. Leider machen es trotzdem viele Firmen, das kann ich aus Erfahrung bestätigen.

...

Viele Grüsse

Joachim

Hoffe deine Frage beantwortet zu haben. Gruss, Robert -- Robert Szentmihalyi, Entracom GmbH Enter and start communication. - http://www.entracom.de solidBITS - The Server On CD Solution - http://www.solidbits.com

Thomas Grieder

11:01

Quoting Robert Szentmihalyi : [ ... ]

...

Dyndns ist grundsätzlich gefährlich und ohne Firewall würde ich das sowieso nicht machen. Leider machen es trotzdem viele Firmen, das kann ich aus Erfahrung bestätigen.

Hallo Was ist denn an dyndns so gefährlich? Gruss Thomas

Robert Szentmihalyi

12:19

On Friday 20 June 2003 13:01, Thomas Grieder wrote:

...

Quoting Robert Szentmihalyi :

[ ... ]

...
Dyndns ist grundsätzlich gefährlich und ohne Firewall würde ich das sowieso nicht machen. Leider machen es trotzdem viele Firmen, das kann ich aus Erfahrung bestätigen.

Hallo

Was ist denn an dyndns so gefährlich?

http://cert.uni-stuttgart.de/archive/bugtraq/1999/08/msg00403.html

...

Gruss Thomas

hth, Robert -- Robert Szentmihalyi, Entracom GmbH Enter and start communication. - http://www.entracom.de solidBITS - The Server On CD Solution - http://www.solidbits.com

Joachim Kieferle

11:10

Robert Szentmihalyi wrote:

...

On Thursday 19 June 2003 23:09, Joachim Kieferle wrote:

...
Robert Szentmihalyi wrote:

...
[ ... ]

Schlechtes Argument. Wenn der Samba Server ohne Firewall direkt am Netz hängt, hast Du sowieso grundlegende Security Probleme (kann nich dir bei Bedarf gerne zeigen). Mit Firewall macht es keinen Unterschied, ob NFS zusätzlich läuft oder nicht, da die Dienste sowieso nur aus dem Intranet erreichbar sind, wenn die Firewall vernünftig konfiguriert ist.

Hallo Robert,

kannst Du zu den "Security Problemen" bitte etwas genaueres sagen? Wie sieht's aus, wenn man in der smb.conf explizit nur die eigene IP-Range freigibt?

Das sollte man sowieso tun. Das ist aber ein schwacher Schutz, denn er verhindert nur, dass SMB requests auf anderen als dem angegebenen interfaces beantwortet werden, zumindest nicht, solange der Angreifer keine Lücke in Samba findet (setzt unter anderem vorraus dass du immer die aktuelle Version am Laufen hast, was bei den meisten nicht der Fall ist), denn die Ports sind ja ohne Firewall immer noch offen. Das ist aber ohnehin der unwahrscheinlichere Fall. Wahrscheinlicher ist, dass der Angreifer über eine andere Sicherheitslücke in dein System eindringt, und wenn der Server ohne Firewall direkt am Internet hängt hat er dann direkten Zugriff auf das Dateisystem des Rechner auf dem sich deine ganzen Daten befinden. Solltest du einen solchen Server am Netz haben, lass halt mal Nessus drüber laufen und lass dich überraschen :-)

Hallo Robert, vielen Dank. Wenn ich es richtig verstehe, ist der offene Samba-Port auch nicht "gefährlicher" als z.B. ein imaps oder http-Port? D.h. jeder offene Port ist per se gefährlich, wenn man ihn also vermeiden kann, sollte man das tun? Viele Grüsse Joachim

Kristian Koehntopp

11:14

On Fri, Jun 20, 2003 at 01:10:45PM +0200, Joachim Kieferle wrote:

...

vielen Dank. Wenn ich es richtig verstehe, ist der offene Samba-Port auch nicht "gefährlicher" als z.B. ein imaps oder http-Port? D.h. jeder offene Port ist per se gefährlich, wenn man ihn also vermeiden kann, sollte man das tun?

Samba ist für Microsoft nicht nur ein Protokoll zum Filesharing, sondern ein Protokoll für den Remote Procedure Call. Die Samba-Ports werden daher von CIFS, dem Windows Filesharing, aber auch von einer Reihe von anderen Diensten (Exchange, File Replication, und viele andere) verwendet. Fortgeschrittene Filewalls interpretieren die Parameter, die bei den Calls auf diesen Ports durchgelassen werden und können spezifische Anwendungen oder Calls blocken (Checkpoint hat da zum Beispiel viele bunte Einsteller für). Kristian

Robert Szentmihalyi

12:02

On Friday 20 June 2003 13:10, Joachim Kieferle wrote:

...

Robert Szentmihalyi wrote:

...
On Thursday 19 June 2003 23:09, Joachim Kieferle wrote:

...
Robert Szentmihalyi wrote:

...
[ ... ]

Hallo Robert,

vielen Dank. Wenn ich es richtig verstehe, ist der offene Samba-Port auch nicht "gefährlicher" als z.B. ein imaps oder http-Port? D.h. jeder offene Port ist per se gefährlich, wenn man ihn also vermeiden kann, sollte man das tun?

Ja. prinzipiell sollten Zugriffe auf nicht benötigte Ports grundsätzlich geblockt werden. Natülich gibt es aber Dienste, die potentiell gefährlicher sind als andere. Über diese Thematik kann man aber ganze Bücher schreiben. Bei näherem Interesse kann ich einige empfehlen.

...

Viele Grüsse

Joachim

Gruss, Robert -- Robert Szentmihalyi, Entracom GmbH Enter and start communication. - http://www.entracom.de solidBITS - The Server On CD Solution - http://www.solidbits.com

Joachim Kieferle

12:38

New subject: Fast OT: Re: Verzeichnisse löschen auf Samba-Share

Robert Szentmihalyi wrote:

...

[ ... ] Ja. prinzipiell sollten Zugriffe auf nicht benötigte Ports grundsätzlich geblockt werden. Natülich gibt es aber Dienste, die potentiell gefährlicher sind als andere. Über diese Thematik kann man aber ganze Bücher schreiben. Bei näherem Interesse kann ich einige empfehlen.

OK, worüber soll ich eines schreiben? SCNR ;-))). Spass beiseite - vielen Dank für Deine Erläuterungen. Leider ist manchmal die Infrastruktur (besonders bei Forschung und Lehre) nicht ganz so "klar" aufgebaut wie in einer Firma, d.h. die Ideallösung lässt sich meist nicht realisieren aber ich hoffe, wir sind relativ nahe dran. Dank Linux habe ich ein relativ gutes Gefühl. Viele Grüsse Joachim

Markus Hoppe

07:30

Am Donnerstag, 19. Juni 2003 16:16 schrieb Robert Szentmihalyi:

...

On Thursday 19 June 2003 15:52, Markus Hoppe wrote:

...
Am Donnerstag, 19. Juni 2003 14:28 schrieb Robert Szentmihalyi:

...
On Thursday 19 June 2003 13:48, Markus Hoppe wrote: [... Stimmt schon, aber der Server hängt am Netz und ich will aus Sicherheitsgründen nur die Dienste laufen lassen, die ich unbedingt brauche. Und weil er hauptsächlich die Windosen bedienen soll, komme ich um Samba nicht herum.

Schlechtes Argument. Wenn der Samba Server ohne Firewall direkt am Netz hängt, hast Du sowieso grundlegende Security Probleme (kann nich dir bei Bedarf gerne zeigen). Mit Firewall macht es keinen Unterschied, ob NFS zusätzlich läuft oder nicht, da die Dienste sowieso nur aus dem Intranet erreichbar sind, wenn die Firewall vernünftig konfiguriert ist. Veto: Natürlich läuft auf dem Server eine Firewall, die alles nach außen zu macht (hoffentlich !?). Darüber hinaus ist der Samba-Server mit den Optionen "interfaces..." und "bind interfaces only..." abgesichert. Aber eine vernünftige Sicherheitspolicy verlässt sich nicht nur auf die Firewall. Nach meiner Philosophie haben Dienste, die nicht benötigt werden, auch nichts auf dem Server zu suchen. Warum also zu Samba noch NFS installieren, wenn das, was ich brauche auch mit Samba geht?

Gruß Markus

7624

Age (days ago)

7625

Last active (days ago)

List overview

Download

13 comments

6 participants

participants (6)

Joachim Kieferle
Kristian Koehntopp
Markus Hoppe
Markus Hoppe
Robert Szentmihalyi
Thomas Grieder