Lokalizacja Instalacji Projektu

0

Mam taki problem do rozwiązania. Od jakiegoś czasu rozwijam projekt oparty na menedżerze plików Total Commander.
Sam menedżer plików rozprowadzany jest ze starannie dobranymi i skonfigurowanymi darmowymi aplikacjami. Problemem jest katalog instalacji dla plików projektu (musi on zapewniać uprawnienia do zapisu).

Ps: Nie za bardzo wiedziałem w jakim dziale umieścić post... projekt powstaje w Delphi, więc padło na Dział Delphi...

Teoretycznie mój problem nie jest problemem (ale tylko teoretycznie). Normalny program w Windows zapisuje pliki instalacji w katalogu instalacji, a swoje ustawienia (i wszystkie pliki, które są zmieniane) przechowuje w katalogu użytkownika, czyli np. C:\Users\Pawel\AppData\Roaming\Test

ALE, mój projekt jest specyficzny - oprócz moich własnościowych aplikacji, instaluję również wiele zewnętrznych aplikacji, które zapisują swoje dane w swoim katalogu. Dlatego, nie mając na to wpływu, muszę zadbać o to, aby miały one uprawnienia do zapisu plików konfiguracyjnych. Dlatego, obecnie stosuje następujące rozwiązanie:

Instalacja w trybie:

  1. PRZENOŚNYM - Przykładowa lokalizacja: C:\Users\Pawel\Desktop\Test
    W trybie przenośnym nie ma problemu - Wszystko instalowane jest w 1 katalogu. Każda aplikacja zapisuje swoje dane w
    swoim katalogu (Katalog instalacji musi mieć oczywiście prawa zapisu).

  2. NORMALNYM - Przykładowa lokalizacja: C:\Program Files (x86)\Test
    W tym trybie wszystko instalowane jest do katalogu Test, który jest podkatalogiem systemowego Program Files (x86).
    Jak wiadomo, katalog ten jest katalogiem chronionym i normalnie programy nie mają prawa zapisu (bez uprawnień administratora).
    W związku z tym, mój instalator zmienia uprawnienia do katalogu instalacji 'Test' (i potomnych)! Dzięki temu, programy mogą normalnie zapisywać dane.

CZYLI:

  1. Czy dobrym pomysłem jest instalacja wszystkiego w katalogu \Program Files\Test i ZMIANA UPRAWNIEŃ dla niego?
    Czym to grozi? Czy niesie to jakieś niebezpieczeństwo dla użytkownika? Czy może to tylko naruszenie zaleceń Microsoft

  2. Jak inaczej można rozwiązać ten problem (bez nadawania uprawnień chronionemu katalogowi)?

  • Czy dobrym pomysłem jest instalacja wszystkiego w katalogu C:\ProgramData\Test?
    Katalog ProgramData to katalog, który jest dostępny dla wszystkich użytkowników i nie wymaga uprawnień administratora.
    Część aplikacji zapisywałaby dane w podkatalogu instalacji (C:\ProgramData\Test), a część z nich w podkatalogu użytkownika (C:\Users\Pawel\AppData\Roaming\Test)

  • A może instalacja wszystkiego w katalogu użytkownika (C:\Users\Pawel\AppData\Roaming\Test)?

Co o tym sądzicie? Jak zrobić to "zgodnie ze sztuką"?

Jestem ciekaw waszych opinii.
Pamiętajcie, że ograniczony jestem zewnętrznymi aplikacjami. Niektóre z nich zapisują swoje dane w katalogu instalacji ( i nie mogę tego zmienić).

-Pawel

0

ze względów bezpieczeństwa wybrałbym opcję 2.
Ostatnio spotkałem się z kilkoma programami, które przy instalacji pytają się czy instalować tylko dla bieżącego użytkownika (AppData) czy dla wszystkich (ProgramData)

0
Paweł Dmitruk napisał(a):

ze względów bezpieczeństwa wybrałbym opcję 2.

Tak... ale co to znaczy ze względów bezpieczeństwa? Jakie jest zagrożenie? Co potencjalny napastnik może zrobić?

Skłaniam się osobiście do zrobienia tak, że:
Instalacja typu All Users (Wszyscy Użytkownicy) -> C:\ProgramData\Test
Instalacja typu Current User (Bieżący Użytkownik) -> C:\Users\Pawel\AppData\Roaming\Test

-Pawel

1

Typowa instalacja programu (nie dotyczy wersji portable) to:

  • wypakowanie plików we wskazanej przez użytkownika lokalizacji,
  • utworzenie folderu na dane użytkownika (do odczytu i zapisu) w katalogu na dane użytkownika — ścieżka dobrana według tego czy dane mają być dla wszystkich użytkowników czy dla bieżącego,
  • dodanie informacji do rejestru (m.in. ścieżka pliku deinstalatora) w gałęzi HKLM_LOCAL_MACHINE, tak aby system widział program jako zainstalowany i dał możliwość jego odinstalowania z poziomu panelu sterowania,
  • utrzownie skrótu na pulpicie, danych w menu Start itp.

A skoro tak, to tutaj nie ma za bardzo nad czym się zastanawiać. Pliki programu głównego — te do odczytu — oraz wszystkie podprogramy wypada wypakować do katalogu wybranego przez użytkownika. Do danych lokalnych powinno trafić wszystko co unikalne dla użytkownika oraz to co wymaga zapisu. W ten sposób uzyska się porządek, a UAC nie będzie przeszkadzać.

0

@furious programming:

Sytuacja nie jest tak prosta. W systemie Windows instalatory pozwalają na instalację plików w zależności od kontekstu powłoki.
Możemy zdecydować się na instalację:

  1. dla aktualnie zalogowanego użytkownika (Current User)
  • W rejestrze Windows korzystamy z gałęzi: HKEY_CURRENT_USER
  • Pliki programów instalujemy do C:\Program Files (x86)\ (32-bit) lub C:\Program Files (64-bit)
  • Ustawienia projektu/programów przechowujemy w C:\Users\Pawel\AppData\Roaming\
  1. dla Wszystkich Użytkowników (All Users)
  • W rejestrze Windows korzystamy z gałęzi: HKEY_LOCAL_MACHINE
  • Pliki programów instalujemy do C:\Program Files (x86)\ (32-bit) lub C:\Program Files (64-bit)
  • Ustawienia projektu/programów przechowujemy w C:\ProgramData\

W zależności od kontekstu powłoki tworzymy skróty (np. na pulpicie czy w Menu Start) w odpowiedniej lokalizacji.

To jest opis normalnej instalacji programu. W moim przypadku jest nieco inaczej. Oprócz własnych programów (które mogę ogarnąć) instaluję również programy firm trzecich. Nie wiem jak zarządzają danymi. Mogą tworzyć własne pliki konfiguracyjne w katalogu instalacji lub katalogu danych użytkownika. Nie wiem tego. Zatem muszę przewidzieć sytuację, że zechcą czytać i pisać dane do pliku konfiguracyjnego, który znajduje się w katalogu instalacji - to oznacza błędy zapisu i problemy.

Stąd moje pytanie. Jaki jest najlepszy sposób instalacji dla takiego typu projektu.
Jak wspomniałem, teraz zrobione mam to tak, że pliki projektu instalowane są do katalogu systemowego C:\Program Files (x86) (lub C:\Program Files dla wersji 64-bitowej), który jest katalogiem chronionym (brak możliwości zapisu bez specjalnych uprawnień) - podczas instalacji ustawiam prawa zapisu dla użytkownika ("$INSTDIR" "(S-1-5-32-545)" "FullAccess", w NSIS).

ALE, metoda taka wg mojej wiedzy nie do końca jest poprawna. Wbrew zaleceniom Microsoft. Tak jak pisałem wcześniej - zastanawiam się jakie naprawdę jest zagrożenie dla użytkownika. Co potencjalny napastnik może zrobić?

Stąd wynika kolejny krok, czyli potencjalnie najlepsza lokalizacja instalacji w tego typu projekcie.
-Pawel

0
Pepe napisał(a):

Zatem muszę przewidzieć sytuację, że zechcą czytać i pisać dane do pliku konfiguracyjnego, który znajduje się w katalogu instalacji - to oznacza błędy zapisu i problemy.

No i właśnie dlatego wszystkie te programy powinieneś instalować w katalogu danych użytkownika, czyli tam, gdzie każdy proces może zapisywać dane. Tylko w ten sposób będziesz miał pewność, że nie będzie problemów z dostępem.

Jak wspomniałem, teraz zrobione mam to tak, że pliki projektu instalowane są do katalogu systemowego C:\Program Files (x86) (lub C:\Program Files dla wersji 64-bitowej), który jest katalogiem chronionym (brak możliwości zapisu bez specjalnych uprawnień) - podczas instalacji ustawiam prawa zapisu dla użytkownika ("$INSTDIR" "(S-1-5-32-545)" "FullAccess", w NSIS).

ALE, metoda taka wg mojej wiedzy nie do końca jest poprawna. Wbrew zaleceniom Microsoft.

Sama instalacja wewnątrz Program Files jest zgodna z zaleceniami Microsoftu. Jedyne co trzeba zrobić to ten instalowany program stworzyć tak, aby nie potrzebował zapisywać danych w sposób ”klasyczny”, czyli obok pliku wykonywalnego (czyli błędnie). Takie coś to sobie mogą robić aplikacje portable, które niczego w systemie użytkownika nie zostawiają — ani na dysku, ani w katalogu użytkownika, ani w rejestrze.

No ale z tego co widzę, wszystko to już wiesz. ;)

Tak jak pisałem wcześniej - zastanawiam się jakie naprawdę jest zagrożenie dla użytkownika. Co potencjalny napastnik może zrobić?

Zabezpieczenia systemu działają wszędzie. Nieważne z jakiej lokalizacji uruchomi się proces, może on zrobić tylko to do czego ma uprawnienia bieżący użytkownik oraz uprawnienia, na które on zgadza się (standardowe lub podwyższone i/lub admina, po potwierdzeniu okna dialogowego). Wątpię, aby deweloperzy Microsoftu nie przewidzieli takiego scenariusza, więc od tej strony nie ma się czym martwić. Ale jeśli chcesz mieć pewne informacje, to sugeruję zapytać na forum MSDN — sam bym tak zrobił.

To co trzeba przewidzieć to typy i przeznaczenie podprogramów, z których główny program ma korzystać. Skąd one się biorą? Ich zestaw sam dostarczasz, czy użytkownik może sobie doinstalować dowolny? A jeśli tak to z puli którą kontrolujesz, czy może to być absolutnie dowolny program? Jeśli sam te programy dostarczasz, a użytkownik nie może dodać swoich (nieautoryzowanych przez Ciebie) to problemu nie ma.

1 użytkowników online, w tym zalogowanych: 0, gości: 1