Daniel =?utf-8?B?TXLDs3o=?= wrote: > Jeśli chodzi Ci o /srv, to takie ustawienie jest dobre i nie widzę > powodu aby dawać tam jeszcze +r dla wszystkich w domyślnej konfiguracji. > PLD ma być w podstawowej konfiguracji zabezpieczony maksymalnie jak się > da. Po to jest ta cała zabawa z grupami disk, audio, video, cdwrite itp.
Chyba nie masz pojecia co oznacza slowo bezpieczenstwo. Grupy daja separacje uprawnien, co oznacza, ze bledu w jednej aplikacji nie da sie wykorzystac do zamieszania w innej aplikacji. > Zabronienie odczytu katalogu /srv userom też podpada pod tę kategorię. A tu nie widze zwiazku. Podasz przyklad? Jesli w ktoryms podkatalogu /srv znajdzie sie plik/katalog o zbyt duzych prawach zapisu (o+w), to ukrycie tego faktu poprzez zabranie prawa odczytu do /srv _nic_ nie zmienia w kwestii bezpieczenstwa. Do pliku sie nadal mozna dostac i go wykorzystac. Dziura jest ten plik. I chyba nikt przy zdrowych zmyslach nie zamierza umieszczac plikow z poufnymi danymi bezposrednio w /srv i dawac im o+r... Dlatego jeszcze raz zapytam: podasz przyklad ilustrujacy dziure w bezpieczenstwie wynikajaca z a+r /srv ? > Zresztą, nie rozumiem w czym jest problem. Przecież można tam utworzyć > sobie katalog usługi, który może być już wykonywalny i odczytywalny > przez wszystkich. Userzy będą mieli dostęp do potrzebnych danych, a > zawartości /srv nie będą mogli oglądać. Tak powinno być. Problem jest, ze ktos moze chciec, zeby inni mieli do niego pelny dostep. A skoro nalezy do FHS, to uprawnieniami do niego powinien zarzadzac rpm a nie admin. Jak chcesz ukryc dane, to umiesc je w go=x /srv/tajne i nikomu to nie bedzie przeszkadzac. Security by obscurity tak naprawde wcale nie zwieksza bezpieczenstwa a jedynie ukrywa jego brak. I bylo to juz w wielu miejscach wielokrotnie walkowane. -- ======================================================================= Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 19 36 Faculty of Applied Phys. & Math., Gdansk University of Technology _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
