Autor Wątek: Prawa dostępu  (Przeczytany 7359 razy)

Offline infernus

  • Użytkownik

# Listopad 14, 2013, 02:16:18
Witam.
Od jakiegoś czasu borykam się z pewnym problemem i wydaje mi się, że ma on związek z prawami dostępu aplikacji do "Program Files (x86)\mojprogram". Gdy próbuję utworzyć plik w katalogu aplikacji (zainstalowanej w Program Files (x86) właśnie) mimo, że nie dostaję żadnego błędu - fopen zwraca wskaźnik i mogę zapisywać, to po zamknięciu pliku fclose (też nie zwraca błędu) pliku nie mogę znaleźć na dysku. Potrzebuję tego bo patchuję aplikację przez neta. Problem nie pojawia się jeśli zainstaluję aplikację bezpośrednio na C:\mojprogram. Czytałem w internecie, że można trzymać pliki podlegające updateom w AppData, ale jak rozwiązać w takim razie sytuację, w której będę chciał zmodyfikować sam plik .exe? Też trzymać go w innym miejscu? Koniec końców okaże się że nic nie będę mógł trzymać w Program Files. Jakie rozwiązane proponujecie?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Xion

  • Redaktor
    • xion.log

# Listopad 14, 2013, 02:19:23
...Zmodyfikować plik .exe? Piszesz malware? ;P

Offline infernus

  • Użytkownik

# Listopad 14, 2013, 02:37:17
Nie, grę. Chodzi mi o update. Jeśli zmienię coś w kodzie, wprowadzę patcha wrzucam to na serwer. User włącza grę, ta sprawdza czy jest coś nowego, pobiera to itd. Jeśli wprowadzę zmiany w samym pliku .exe to go też muszę pobrać prawda? Znalazłem już coś na temat UAC self elevation - to chyba dobry trop.

Offline albireo

  • Użytkownik

# Listopad 14, 2013, 08:31:11
UAC self elevation to dobry trop, a co do problemu z modyfikacją katalogu Program Files, to wynika on z tego, że od Visty (o ile mnie pamięć nie myli) MS wprowadził zabezpieczenie modyfikowania tego katalogu przez programy bez wyższych uprawnień, ale że wiele starego oprogramowania modyfikuje pliki w katalogach instalacji, to zrobili obejście poprzez zapisywanie tych plików gdzieś w profilu.

Offline laggyluk

  • Użytkownik
    • twitter

# Listopad 14, 2013, 09:50:50
updater musi mieć 'prawa admina', sama gra już niekoniecznie. do tego jeżeli nie chcesz żeby za każdym razem wyskakiwał monit kiedy jest nowa wersja to musiałby działać jako usługa

Offline Xender

  • Użytkownik

# Listopad 14, 2013, 12:25:12
Rozprowadzać grę w ZIP (ew. samorozpakowującym się) i niech user sobie rozpakuje tam, gdzie ma prawa dostępu. Rozwiązanie godne systemu, w którym nie ma managera pakietów. ;>

Bardziej serio, to logiczne byłoby, żeby updater zachowywał się podobnie do instalatora - jak instalator wymaga AUC, to niech updater też wymaga. Java Update tak robi, więc może dużo lepiej się nie da?
« Ostatnia zmiana: Listopad 14, 2013, 12:30:14 wysłana przez Xender »

Offline infernus

  • Użytkownik

# Listopad 15, 2013, 05:13:12
W skrócie używam kodu autopatchera RakNet a w praktyce to teraz problemem jest, której aplikacji powinienem zwiększyć uprawnienia. Gra ich nie wymaga więc z nią nie ma problemu. Za update ma odpowiadać Launcher, czyli on musi je posiadać. Tylko, że w wypadku gdy Launcher również podlega updateowi jest usuwany przez inną aplikację (bo samego siebie nie może usunąć) -"Autopatcher restarer". Więc ta aplikacja również wymaga tych praw. Chyba, że aplikacja uruchamiana przez aplikację o wyższych uprawnieniach je dziedziczy? Bo jeśli nie, to pojawia się jeszcze jeden problem bo "Autopatcher restarter" uruchamia skrypt przez CreateProcess - czy w tym wypadku jest jakaś opcja nadania uprawnień? Jak wygląda taki proces patchowania w przeglądarkach np.: Firefox, Opera? Bo dokładnie o takie coś mi chodzi. User włącza grę poprzez launcher, dostaje monit o updacie klika OK. Następuje update wszystkiego i restart.

Offline Xion

  • Redaktor
    • xion.log

# Listopad 15, 2013, 07:23:54
Cytuj
Za update ma odpowiadać Launcher (...)[który] jest usuwany przez inną aplikację (bo samego siebie nie może usunąć) -"Autopatcher restarer"
Za update powinien odpowiadać updater, tj. program który pobiera aktualizację i ją aplikuje.

Cytuj
Chyba, że aplikacja uruchamiana przez aplikację o wyższych uprawnieniach je dziedziczy?
Chciałbyś. Zapominasz, że nie mówimy o normalnych systemach operacyjnych, tylko o Windows :)

Cytuj
"Autopatcher restarter" uruchamia skrypt przez CreateProcess - czy w tym wypadku jest jakaś opcja nadania uprawnień?
Jest CreateProcessAsUser, ale na oko jakieś 85 razy łatwiejsze jest wyposażenie aplikacji updatera w odpowiedni manifest bądź użycie ShellExecuteEx.

Offline Karol

  • Użytkownik

# Listopad 15, 2013, 09:48:07
Btw. jak użyjesz w nazwie programu słówka update to UAC samo wyskoczy :D (nawet jak program nie wymaga żadnych uprawnień).

Jakiś czas temu (kurde, 3 lata), badałem lekko ten temat i ustanowiłem sobie taką procedurę aktualizacji:
  • Sprawdzenie czy jest dostępna aktualizacja, jak nie to koniec
  • Pobranie plików do aktualizacji
  • Wypakowanie z zasobów exeka małego programiku* potrzebnego do wykonania autoaktualizacji
  • Wygenerowanie pliku bat, który poczeka na zamknięcie exeka, podmieni plik i uruchomi go ponownie
  • Uruchomienie pliku bat i zamknięcie exeka
  • Plik bat robi co ma robić, na koniec usuwa sam siebie
  • Aktualizacja zakończona

* głównym celem tego programu jest wstrzymanie wykonywania pliku bat do momentu zamknięcia aplikacji, więcej o tym tu http://karol.infcore.net/2010/09/03/aktualizacje-aplikacji/
« Ostatnia zmiana: Listopad 15, 2013, 10:00:57 wysłana przez Karol »

Offline koirat

  • Użytkownik

  • +1
# Listopad 15, 2013, 11:53:37
Ja bym kombinował raczej z dll-kami:

Aplikacja uruchamia updater.dll

Aplikacja unloaduje updater.dll na wypadek gdyby miała go nadpisać.

Aplikacja updatuje pliki ściągnięte, dodaje nowe i nadpisuje stare.
Tu można się pokusić o kolejną dll-ke która by to robiła, dzięki temu w przyszłości można by to robić za pomocą patch-owania a nie ściągania całych plików.

Na koniec aplikacja uruchamia dll-kę z programem.

Nie nie modyfikujesz pliku exe, ale w sumie przy tym systemie nie ma takiej potrzeby.
« Ostatnia zmiana: Listopad 15, 2013, 11:56:34 wysłana przez koirat »

Offline Dab

  • Redaktor
    • blog

# Listopad 15, 2013, 12:33:52
A po co tak strasznie kombinować? :)

1. W Program Files instalujesz dwie binarki - Launch.exe i Game.exe.
2. Launch.exe sprawdza czy jest na zdalnym serwerze aktualizacja. Jeżeli tak, to zapisuje nowy Game.exe do Application Data
3. Launch.exe uruchamia grę przez Game.exe z Application Data, a jeżeli go tam nie ma to ze swojego katalogu

Offline koirat

  • Użytkownik

# Listopad 15, 2013, 14:26:33
Ciekawe aczkolwiek przyznam szczerze ze nie podoba mi się idea odpalania aplikacji z AppData.

Ogólnie to nie podoba mi się sama idea rozproszenia danych w tak odległych miejscach dla jednej aplikacji.
Szczególnie jeśli te dane są krytyczne dla poprawnego uruchomienia.

Rozumiem że ten sposób rozwiązuje większość problemów z prawami dostępu ?

Offline Xion

  • Redaktor
    • xion.log

  • +1
# Listopad 15, 2013, 18:42:41
@Dab: W ten sposób nie zapdejtujesz launchera.

Cytuj
Ogólnie to nie podoba mi się sama idea rozproszenia danych w tak odległych miejscach dla jednej aplikacji.
Jest to standardowa praktyka w (teraz już) wszystkich systemach operacyjnych, która oprócz "obchodzenia problemów" z prawami dostępu pozwala np. programom na oddzielanie opcji konfiguracyjnych właściwych poszczególnym użytkownikom.

Offline Karol

  • Użytkownik

# Listopad 15, 2013, 19:06:34
Jest to standardowa praktyka w (teraz już) wszystkich systemach operacyjnych, która oprócz "obchodzenia problemów" z prawami dostępu pozwala np. programom na oddzielanie opcji konfiguracyjnych właściwych poszczególnym użytkownikom.
Myślę, że dla koirata nie chodziło o pliki konfiguracyjne per user (bo to jest spoko), tylko binarki gry tu, binarki gry tam, włączasz jedno to uruchamia się co innego itp.

Offline koirat

  • Użytkownik

# Listopad 15, 2013, 19:07:43
[edit]Jak już @Karol wspomniał.[/edit]
Miałem dopisać wcześniej "z pominięciem danych przechodnich jak pliki konfiguracyjne" ale już mi się nie chciało :P, oczywiście wiem że jest taka praktyka.

Co do update-u launcher-a w stylu @Dab to zawsze można przekopiować launcher.exe i dopiero odpalić przekopiowany.
Ale ogólnie i tak mi się nie podoba ta idea, choć może być to osobiste odczucie :).