Możliwość braku uprawnień do zapisu w systemowym katalogu lokalnych danych

0

Czy może zaistnieć taka sytuacja, że program uruchomiony z bieżącymi uprawnieniami użytkownika (gdy aplikacja używa opcji asInvoker) nie będzie mógł np. utworzyć katalogu lub pliku w systemowym katalogu %LOCALAPPDATA%, czyli nie będzie miał praw zapisu w tym folderze?

Biorę pod uwagę wszystkie możliwości, zarówno typy użytkowników (administrator, użytkownik, gość), jak i możliwość przypadkowego/celowego zablokowania praw do zapisu przez użytkownika; O ile blokowanie tego katalogu było by głupotą to niestety głupota użytkowników jak wiadomo nie zna granic :]


Implementuję sobie właśnie mechanizm tworzenia dedykowanego katalogu z konfiguracjami programu i zastanawiam się, czy jest sens wprowadzać zabezpieczenie przed brakiem możliwości utworzenia folderu przez funkcję CreateDirectoryUTF8; Argumentem tej funkcji jest ścieżka pobrana przez API systemu z dodaną podścieżką - całość będzie posiadać poniższą postać:

%LOCALAPPDATA%\MyCorpoName\MyAppName\

więc na tym etapie zawsze będzie prawidłowa (jeśli funkcja API systemu nie zdoła pobrać ścieżki tego katalogu to do tego kroku program nie dojdzie); Priorytetem dla mnie jest zabezpieczenie wszystkiego, co może spowodować całkowite wykrzaczenie programu i swoisty UB;

Samo dodatkowe zabezpieczenie istniejące w kodzie w niczym nie przeszkadza, chodzi po prostu o zaspokojenie mojej ciekawości; Aplikacja będzie działać na systemach Windows od wersji XP wzwyż.

1

W XP chyba nie ma zmiennej środowiskowej %LOCALAPPDATA%. Folder o tym samym przeznaczeniu był pod ścieżką %USERPROFILE%\Local Settings\Application Data\

Co do uprawnień to domyślnie do tego folderu może zapisywać System, Administrator i zalogowany użytkownik. Gość i inni użytkownicy tego samego systemu nie mają przypisanych żadnych uprawnień. No i najważniejsze każdy użytkownik ma swój folder podpięty pod %LOCALAPPDATA%. Pełna ścieżka wygląda na przykład tak: C:\Users\USERNAME\AppData\Local.

Btw. W nowszych wersjach Windowsa jest fajna opcja do sprawdzania uprawnień. Wystarczy kliknąć prawym przyciskiem myszy na pliku lub folderze wybrać kolejno: Właściwości -> Zabezpieczenia -> Zaawansowane -> zakładka dostęp czynny. Potem trzeba wybrać użytkownika lub grupę i kliknąć Wyświetl dostęp czynny. Wybrać można na dwa sposoby:

  1. wpisać nazwę według schematu: nazwa komputera\nazwa użytkownika
  2. kliknąć Zaawansowane, później Znajdź teraz i wybrać z wyszukanej listy
0

W XP chyba nie ma zmiennej środowiskowej %LOCALAPPDATA%. Folder o tym samym przeznaczeniu był pod ścieżką %USERPROFILE%\Local Settings\Application Data\

To nie ma znaczenia - ścieżkę tego katalogu jak napisałem pobieram za pomocą WinAPI, a dokładniej za pomocą funkcji SHGetSpecialFolderPathW i stałej CSIDL_LOCAL_APPDATA, dla kompatybilności z WinXP; Dla wyjaśnienia, pod WinXP ścieżka tego katalogu wygląda tak:

C:\Documents and Settings\UserName\Ustawienia lokalne\Dane aplikacji

W nowszych wersjach systemu ścieżka wygląda inaczej; To także nie ma znaczenia w tym przypadku, bo i tak ścieżkę pobieram dedykowaną funkcją WinAPI;

No i najważniejsze każdy użytkownik ma swój folder podpięty pod %LOCALAPPDATA%. Pełna ścieżka wygląda na przykład tak: C:\Users\USERNAME\AppData\Local.

@Tajiri - nie tłumacz mi tego kto jakie foldery ma, bo ja to wiem; Wiem, że każdy użytkownik ma ten katalog - przecież po to właśnie z niego korzystam (zresztą Microsoft zaleca używanie tego katalogu - o tym można wyczytać na stronie MSDN); Aplikacja ma przechowywać m.in. ustawienia oraz statystyki osobno dla każdego użytkownika, więc to jedyna rozsądna lokalizacja na dane modyfikowane po każdym użyciu programu (uruchomieniu i zamknięciu);


Pytanie zadałem, czy może zaistnieć sytuacja, że aplikacja nie będzie miała praw zapisu w tym katalogu; Bo nawet konto gościa ma swój katalog danych lokalnych - na WinXP ścieżka wygląda tak:

C:\Documents and Settings\Gość\Ustawienia lokalne\Dane aplikacji

Czyli teoretycznie program może próbować zapisywać tam swoją konfigurację - i dobrze, to ważne; Co najwyżej może wystąpić problem z uprawnieniami do zapisu, ale ich nadanie leżeć będzie po stronie użytkownika, a nie programu; Z tym kontem gościa trzeba by znaleźć jakieś rozwiązanie - muszę to posprawdzać na Win7 i nowszych systemach;

Na to wychodzi, że jednak może wspomniana sytuacja zaistnieć - dziękuję za informacje; Czy ma ktoś coś jeszcze do dodania?

0

Używam tej lokalizacji w swoich programach. Lekko licząc ponad 1000 konfiguracji sprzętowo systemowych. Nigdy nie miałem problemów z uprawnieniami. Nie testowałem z kontem gościa...

0

Nie testowałem z kontem gościa...

No, w takim razie nie zdziw się, jak program zacznie ładować błędami :]

Swoją aplikację przetestowałem na świeżo utworzonym koncie gościa (pod WinXP - póki co tylko nim dysponuję) i dostałem elegancko komunikat o niemożności utworzenia katalogu podczas próby ładowania danych konfiguracyjnych (swój komunikat, czyli wszystko działa prawidłowo);

W każdym razie to co @Tajiri napisał sprawdza się - domyślnie nie ma uprawnień do zapychania tego katalogu przez gościa.

1

może nie mieć dostępu - wystarczy wejść w opcje dostępu i przejąć ten katalog na własność z innego usera a potem zabronić zapisu innym do niego. Ale to praktycznie rozkłada danego usera na łopatki i mało który program mu się uruchomi.
Czyli może zajść sytuacja, że się wykrzaczy, tylko że wtedy wykrzaczy się też cała reszta programów korzystających z tej ścieżki.

To wg mnie podpada pod wejście (na XP np.) do katalogu windows i wyrżnięcia np. katalogu system32 - dać się da tylko sensu nie ma za wiele

0

Ja wiem @abrakadaber, że to sensu nie ma - potrzebna mi była wiedza jedynie o tym, czy jest możliwe zablokowanie dostępu do tego katalogu; I jak widać jest to możliwe - przez użytkownika (celowe działanie) lub system (konto gościa); Szansa, że u użytkownika takie problemy zaistnieją jest mała, ale istnieje - dlatego też zabezpieczenie przyda się;

Skoro już w sumie obawy potwierdziły się - wątek można zakończyć; Dziękuję za zainteresowanie :]

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