STAR TREK 2d20
Page 3 of 9 First 12345 ... Last
  1. #21
    To be honest: I'm very disappointed the fix for permissions is just to allow everyone read/write access to the FG program folder. That's not a fix, that's a workaround and a bad one. There are reasons why installers ask for permissions to write to those folders.

    That's like taken straight from the book of "shitty admin advice" to run 'chmod 777' to fix permissions and afterwards wondering how your system got compromised. When I received the popup I was wondering what the hell is going on, since I never had any issue with running FGC/FGU and the updater. And since there is also no "nope don't want to move forward without knowing whats going on" in that popup I checked the install folder afterwards and was pretty SURPRISED to see those write permissions.

    Now the updater is not even starting anymore if I remove those permissions... great. And during the initial permission fix process for some reason I ended up after the "fix" with TWO FGU instances running and the updater complaining that it can't update because of the other instance.

    Edit: Sorry I went a bit on a rant here, still think all the above is valid.
    Last edited by Speculi; April 26th, 2020 at 16:16.

  2. #22
    I updated Fantasy Grounds last night, and again this morning. Yesterday I had no special prompts and it felt like any other update. I use default file locations and have not had permissions problems.
    However on today's update, I got a prompt about fixing permissions (I clicked OK). And after the updating was done, Fantasy Grounds started, but also the updater seemed to launch again (and prompt that FG is currently running, and the dialog will close when FG is closed). Since I didn't need to update, I tried clicking the X to just close the updater engine, but it was stuck in a loop and just kept relaunching and I had to close FG to get out of it.

    Aside from the multiple separate bugs with the launcher, I 100% agree with Speculi's post above. Adding the Everyone role with full control (that's additional access beyond just read/write access, including rights to further change permissions) is pretty terrible. Given that this is still in beta, it's tolerable for now but please please find a better solution before the gold master release.
    Edit: Also, I want to say that I'm concerned that because permissions are getting set to allow Full Control to Everyone, unless a future update specifically removes that, it is going to be extremely difficult to get good testing results out of future refinements to find what exactly the settings need to be
    Last edited by TheSlowestZombie; April 26th, 2020 at 21:50.

  3. #23
    The Full Control permissions are only being granted to the FG application folder where the program files reside. This allows us to update the program files without having to request admin access on every single check for updates. We decided on this approach after noting that this was the approach used by some major publishers. I verified on my machine that this is how Blizzard handles program updates for at least some of their applications.

    Otherwise, the problem becomes that it every update requires admin escalation, and that there are not any built-in mechanisms to "de-escalate" a process in .Net or in either Mac or Windows OS. So, the issue is that the updater has to be escalated, and the "rights" of any programs spawned by the escalated process are also escalated. The net result is that the program is sometimes run by the "logged in user", and after updates, it is run as the "admin user". For most people, this is the same user; but for those with more complex user setups, it becomes a problem where the program gets run as two different users depending on whether you update or not.

    Regards,
    JPG

  4. #24
    I'm, not a developer, but I think that other programs like Google Chrome have solved this by doing the following: During the initial install, create a scheduled task that has admin rights. You don't need any special triggers defined, but it would be configured to run with highest elevation permissions, and all it would do is launch the FG updater.
    Then, when users click Check for Updates, just manually trigger the scheduled task. It won't prompt for admin elevation from the user, but it will run with administrative rights.

    Alternatively, could you just script something to get the username of the currently running fg process, and add full control permissions for just that account? On shared systems, each user would one time after approve admin access, but after that they'd have the permissions they need.

    Or yet another option, in Active Directory, there's a built-in group called Authenticated Users. I'm not sure if that is also a built-in account on individual computers but if it is you could use that to grant permissions and it'd still be better security than assigning rights to Everyone.

  5. #25
    That's what we're doing to adjust the permissions on the FG application directory. By doing it as a change and check, we reduce how often we need to request admin rights to a minimum.

    Regards,
    JPG

  6. #26
    Quote Originally Posted by Kelrugem View Post
    It still does not work for me, the popup is still there and my version is still the 22. of April; shall I maybe simply reinstall? (the updater is at the 23. of April) I have the feeling that I can't get any update anymore, so a new install might help
    I just wanted to reinstall (also because that seemed to fix the stucked pop-up for others), but I can't access the deinstall button in the settings due to the stuck pop-up; FGU is also not listed in the software-list under Windows such that I can't deinstall it there I could try to do it manually, but the last time I messed up things then (but I remember how to do that, I guess)

    Should I maybe simply wait, or can I reinstall manually? Just want to make sure that I do not start something bad
    Last edited by Kelrugem; April 27th, 2020 at 00:24.

  7. #27
    Quote Originally Posted by Moon Wizard View Post
    The net result is that the program is sometimes run by the "logged in user", and after updates, it is run as the "admin user".
    This is why other software first downloads program updates, then *immediately* run the installer via admin rights and restart the process to finally install content updates.

    Blizzard does the same with their Battle.net software, as does Steam, they always restart after running the updater for their own clients. They don't mix client updates with content updates (aka games), it's two distinctly different updates processes. Same goes for Hero lab, where it installs the program using admin rights and then restarts the client immediately, content can be installed using normal user directly without a restart.

    Personally I tend to install games into their own sub-directory on the main/root drive. Keeps things tidy and any such file permission ugliness is circumvented. An audio software called Ableton Live used to work around the issue by installing its software into the "ProgramData" folder instead, which is more permissive.

    That being said, there is a reason why software is kept in a permission restricted location: to keep other software from easily messing with it, be it accidental deletion or malicious modification. You remember all those viruses of old that would just append their code to already present .exe and .com files?
    Last edited by Weissrolf; April 27th, 2020 at 08:58.

  8. #28
    Quote Originally Posted by Moon Wizard View Post
    We decided on this approach after noting that this was the approach used by some major publishers. I verified on my machine that this is how Blizzard handles program updates for at least some of their applications.
    Steam appears to at least use the "Users" group rather than "Everyone" which would at least cut out the guest account and non-interactive limited-privilege system accounts. It would still open up write access to non-admin human users, but certain kinds of privilege escalation tricks started from low-privilege access would be unable to abuse FG's permissions to overwrite FG binaries and then subsequently run as a more privileged human's account when someone tries to start FG.

    But I also think TheSlowestZombie's proposal to create a elevated privilege task and Weissrolf's suggestion of using UAC but then restarting after the update are worth consideration if they work. I certainly would not mind saying "yes" to a UAC prompt for each update, if that's the remaining "problem" after adopting such suggestions.

  9. #29
    Quote Originally Posted by Kelrugem View Post
    I just wanted to reinstall (also because that seemed to fix the stucked pop-up for others), but I can't access the deinstall button in the settings due to the stuck pop-up; FGU is also not listed in the software-list under Windows such that I can't deinstall it there I could try to do it manually, but the last time I messed up things then (but I remember how to do that, I guess)

    Should I maybe simply wait, or can I reinstall manually? Just want to make sure that I do not start something bad
    I was able to fix that: I manually gave "user" the permission to the app folder, and then finally the pop-up was gone. But I was still stuck on the wrong version, so, I had to reinstall (which was now possible without manual deletion due to that the pop-up was finally gone)

  10. #30
    I tried to install and uninstall, delete the registry, use the old installer but the FGU does not come out of this splice when updating after installing.
    FGU crash.jpg

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
5E Character Create Playlist

Log in

Log in