Windows server installs in elevated admin profile rather than shared or current user profile

[ptr727]

Summary: Emby installs in admin user account instead of local user account, or instead of common shared folder location.

Emby Server for Windows 3.0.5724.6.
Installed on Windows Server 2012 R2 x64.

Installed from regular user account "Media_Player", not an administrative account.
Installer requires elevation during installation, UAC elevated using "Administrator" account.
Installer installs binaries in %appdata% folder, "C:\Users\Administrator\AppData\Roaming\Emby-Server" folder.
Installer spawns Emby, since installer is running in Administrator account context, and installed in Administrator folder, the app is running in the "Media_Player" windows session, but under the "Administrator" user context.

Any shares mapped to "Media_Player", or any UNC network permissions mapped to "Media_Player", fail to mount shares in Emby, as the actual user session under which Emby is running is the "Administrator" account, not the current "Media_Player" account.

On stopping Emby, it is impossible to restart Emby, as all the installer shortcuts were created under the "Administrator" account, i.e. the account used for elevation, not the all users "%programdata%" folder, nor the all users shortcuts folders.

Expected behavior:

1. Install in a shared location, accessible to all users on the system.
   Either %programfiles" that requires admin privileges to install and update.
   Or %programdata% that does not require elevation to install and update, and is available to all users.
   Or %appdata% folder that does not require elevation to install and update, and is only available to the current user.

2. Run in the context of the currently logged on user.
   Regardless of install location, run in the context of the current user.
   Allowing network permissions to be inherited from the current user session.

Refer to forum post: http://emby.media/community/index.php?/topic/26315-unable-to-add-unc-media-paths/

[ebr11]

This is by design at this point in time.

We install to the user-specific area instead of a common location because this is the only way we can ensure our automatic update routines will work completely unattended.

Given that, we install to the first admin account to minimize the situation where someone installs the server multiple times on the same machine into multiple different user accounts.

[ptr727]

Please see the forum discussion, a couple highlights.

You run a remotely accessible web server, under admin privileges, exposing the system to remote attack.

I understand that you want to install to a location where elevation is not required, and keep your footprint small, and you can self update without needing to elevate.
But, I think your current design falls short of those objectives, it follows bad security practices and bad Windows deployment practices.

You require elevation during install so the VC redist installer can run, you continue running in that elevated context, and install the bits to disk in that account context, ending up installing in the admin account profile. (Not the first admin account as you state, the account selected by the user that allows admin elevation) You then launch the process, while still in the same elevated context, and end up running in the current user windows session, but under the admin account credentials.

From this point it is impossible for this user to relaunch the app, as the app was actually installed in the admin account, not this account. The web server is now also running with admin privileges, from an admin account. Web server, remotely exploitable, running in an admin account...

To get back your objective:

• Allow installs inside non-admin accounts, if elevation is ever required, drop back to this user context.
• Run the network code with least privileges, certainly not as an admin.
• Install in "%programdata%" for all users or in "%appdata%" for this user.
• Install the VC runtime side-by-side, i.e. copy the DLL's next to your binaries in the install folder, do not run the redist. Pay attention to the VC redist EULA, not all files may be distributed outside of the redist installer. Or link statically to the VC runtime

[ebr11]

I'm pretty sure the only reason we elevate right now is to cause the server to be installed into a single, repeatable user account even if the user installs it from multiple users.

This elevation can probably be removed with the only repercussion being that the server will get installed into whatever user account is running the installer. We cannot go into a common area (other than the admin user area). We have been down this road and it simply isn't reliable.

If someone wants to make the change to the installer such that it doesn't request elevation and thoroughly test it with both existing and new installs, then I'm game for that.

[LukePulverenti]

Now that we're using github releases, you can just grab the windows zip and run the server portable from wherever you like.

https://github.com/MediaBrowser/Emby/releases