• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

openssh-sftp-server ->buggy umask-SETGIT-BIT geht verloren

lin

Hacker
halli hallo liebe linux-freunde,


auf einem openSuse Linux server

arbeite ich mit einem Fielezilla SFTP-client

der Setup: OpenSuse 11.4 auf dem lokalen Rechner!

Code:
FileZilla Client
----------------
Version:          3.3.4.1
Build information:
  Compiled for:   i686-pc-linux-gnu
  Compiled on:    i686-pc-linux-gnu
  Build date:     2011-02-23
  Compiled with:  gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]
  Compiler flags: -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector 
- funwind-tables -fasynchronous-unwind-tables -g -fstack-protector -Wall -g -fexceptions

Linked against:
  wxWidgets:      2.8.11
  GnuTLS:         2.8.6

Operating system:
  Name:           Linux 2.6.37.6-0.7-default i686
  Version:        2.6

Der Server wird von einem Freund administriert. Er ist was die user anbelangt sehr sicherheitsbewusst. Er arbeitet deshalb mit dem SETGIT bit, das er voreinstellt bzw. den Verzeichnissen in denen ich was installieren will - ( eine Drupal oder ein Joomla -CMS) verleiht... bzw. es so entsprechend einrichtet.

das Problem - jedesmal wenn ich nur etwas an den Rechen ändere - mit FileZilla (siehe oben), dann bekomme ich viel viel stress. Denn dann geht
jeweils das SETGIT-BIT verloren..!!!

Nebenbei bemerkt: Filezilla beherrscht das SETGIT BIT ja gar nicht- Damit kann man das SETGIT-Bit ja im Grunde gar nicht einstellen. Aber dennoch denke ich dürfte das SETGIT-Bit nicht so einfach verloren gehen - was meint ihr hierzu...

Jetzt könnte es aber sei dass das ja überhaupt nicht FileZilla ist - der den Fehler verursacht - das "verschwinden des SETGIT-Bits ausloest!"

Kann es denn nicht sein dass es das umask ist, das sftp verwendet?

Was ist denn wenn der Fileserver buggy ist...?!? Ich mein - was wäre denn dann. Dann würde es wohl helfen wenn ich ein anderes umask verwende...
und dann von
Code:
 Subsystem sftp /usr/libexec/openssh/sftp-server
auf Subsystem sftp /bin/sh -c 'umask 0002; /usr/libexec/openssh/sftp-server'

in der sshd_config Datei des Servers wechsle.


Hmmm - Danach solle ich den Server wieder frisch starten - und werde wohl dann festestellen, dass das SETGIT-Bit auch gespeichert bleibt, wenn das
übergeordnete Verzeichnis so eingestellt ist.

Meine Frage - gibt es denn so etwas - so buggy SSHD-Files bzw. SFTP-Server die so viele Fehler machen.

Freu mich auf einen Tipp.

viele Gruesse
lin
 

spoensche

Moderator
Teammitglied
Karma-Karmelion schrieb:
Hast du schon einmal versucht nicht mit FileZilla auf den Server zuzugreifen? Oder eine aktualisierte Version von FileZilla genutzt?

Das hat nichts mit Filezilla zu tun.


@lin:
Dein Filezilla ändert die Rechte, weil du als Eigentümer der Datei o. als Mitglied der Gruppe die dafür nötigen Berechtigungen besitzt. Mit dem SGID- Bit kann dein Freund den Server nicht absichern oder dem Eigentümer der Datei bzw. den Gruppenmitgliedern die Änderung der Rechte verbieten.

Wenn das SGID- Bit auf einem Programm gesetzt ist, dann wird das Programm immer mit den Rechten der angegebenen Gruppe ausgeführt, egal ob der User Member der jeweiligen Gruppe ist.

Das SGID- Bit ist quasi nichts anderes als das SUID-Bit, nur das dass SGID Bit sich auf Gruppen bezieht.

Das Sticky Bit hat Einfluss auf Verzeichnisse.

Wenn dein Freund mit den Gruppenrechten den Zugriff regeln will, dann kann er das per ACL machen oder ihr seid Mitglied oder eben kein Mitglied der Gruppe und dürft dort was schreiben.

Wenn er allerdings nur einer bestimmten Gruppe den Zugriff per SSH/SFTP (Einloggen etc.) erlauben möchte, bleibt nur noch ACL.
 
OP
L

lin

Hacker
hallo ihr Beiden

vielen Dank für die vielen Infos. Das Thema ist im Moment nicht so furchtbar akut. d.h. mitterweile geht viel was früher nicht gegangen ist. Werd mich mal in die entscprenden Kapitel der Linux-Kiste einlesen.

Melde mich hier wieder.
lg
 
Oben