Użytkownik widzi tylko swoje pliki

[BlueMan 69]

Co, jak i gdzie należy poustawiać, aby użytkownik w systemie (Debian) widział i mógł się dostać tylko do swoich plików (wewnątrz UID, lub GID)?

[Gość patrys]

google: chroot

[pxw 0]

A nie wystarczy odpowiedni chmod? :>

[p 3]

A nie wystarczy odpowiedni chmod? :>

Wszystko zależy od tego co dokładnie miał na myśli BlueMan. Możliwe, że wystarczy, ale w ogólności potrzebny jest chroot / jail.

[BlueMan 69]

Aby tworząc konto ftp/ssh na moim serwerze użytkownik nie mógł widzieć moich plików i plików systemowych. Nie mógł chodzić pod drzewie katalogów, itp.

 

http://www.howtoforge.com/chroot_ssh_sftp_debian_etch - ten tutoriał będzie dobry i wystarczający?

[kafi 2425]

Przy FTP odpowiednia konfiguracja home-dir'a powinna zamknąć użytkownika w swoim katalogu, nawet bez chrootowania.

 

Przy SSH tylko chroot. Ale jeśli użytkownik ma "nie widzieć" plików systemowych, to po co właściwie mu wtedy SSH?

[p 3]

http://www.howtoforge.com/chroot_ssh_sftp_debian_etch - ten tutoriał będzie dobry i wystarczający?

Nie, ten tutorial jest beznadziejny...

[BlueMan 69]

Przy SSH tylko chroot. Ale jeśli użytkownik ma "nie widzieć" plików systemowych, to po co właściwie mu wtedy SSH?

Po to co w każdej firmie hostingowej aby sobie zarządzał swoimi plikami, a nie mieszał palców w nie swoje rzeczy

 

 

@p - polecisz coś dobrego, dla moich potrzeb?

[pxw 0]

Po to co w każdej firmie hostingowej aby sobie zarządzał swoimi plikami, a nie mieszał palców w nie swoje rzeczy

 

 

@p - polecisz coś dobrego, dla moich potrzeb?

Mieszać nie będzie, bo nie będzie miał prawa zapisu. Owszem, można dać na przykład chmod 711 na systemowe sprawy, tylko po co? To jest takie security by obscurity. Jeżeli ktoś nie jest wystarczająco zaufany, by oglądać configi w systemie, to znaczy, że w ogóle nie jest wystarczająco zaufany, by mieć dostęp do powłoki systemowej. Co do firm hostingowych, to tu muszę przyznać, że mam dosyć niewielkie doświadczenie, ale tam, gdzie miałem konta, to możliwość oglądania /etc w tym pliku passwd była i nic się nie działo. Jeżeli chodzi o konta userów, to klasycznie chmodem. To jest wystarczające i to się powszechnie do tego stosuje na tzw. shellowniach i innych hostingach, gdzie konta userów są kontami systemowymi. Jedno, na co warto by było zwrócić, to na to, że o ile kwestie hostowania stron zrobisz w ,,standardowy" sposób (czyli public_html z chmodem 755 w $HOME), to tam już ,,obyci" userzy sobie zajrzą, jak będą chcieli (warto wiedzieć, jak się zamierza trzymać jakieś autorskie cms-y chociażby). Czemu powiedziałem, że ,,obyci"? Ano dlatego, że osoba świeża, zazwyczaj chodząca po katalogach za pomocą mc już tam nie wejdzie, skoro do będącego przed publiciem $HOME nie będzie miała praw.

Trochę to zagmatwałem, ale mam nadzieję, że nieco objaśniłem i przy okazji wspomniałem o czymś istotnym, niby oczywistym, a jednak często pomijanym na początku.

[p 3]

@p - polecisz coś dobrego, dla moich potrzeb?

Dokumentację? Wszystko sprowadza się do ustawienia kilku zmiennych...

Poza tym bezmyślne kopiowanie poleceń z tutoriali nie może prowadzić do niczego dobrego

[kafi 2425]

Po to co w każdej firmie hostingowej aby sobie zarządzał swoimi plikami, a nie mieszał palców w nie swoje rzeczy

Sprecyzuj, co to są "nie swoje rzeczy".

Czy np. binarka MC to już "nie swoja rzecz"? Czy wget to "nie swoja rzecz"?

Jak by nie patrzeć, są to pliki systemowe...

Jeśli twoja odpowiedź będzie, że to "swoja" rzecz - to zastanów się, jak rozróżniać to, co wolno, od tego, czego nie wolno. Chroot + kopiowanie plików jest IMO lekkim marnotrawstwem.

 

Poza tym - tak jak pxw napisał - jeśli ktoś jest na tyle mało zaufany, że nie powinien oglądać plików systemowych, to musi poprzestać na koncie FTP + jakiś ajaxplorer.

A jeśli kogoś darzy się jakimś zaufaniem, to dostaje SSH...

 

PS: Dostęp do pliku /etc/passwd i /etc/shadow jak najbardziej w pewnych specyficznych przypadkach może być nawet z uprawnieniami 777