Jump to content

Not UAC compliant and other compliance issues


Link

Recommended Posts

Mediabrowser3 server asks for elevation to install- but why it does this I haven't the faintest idea, because it installs to the user folder, which does not require elevation...

 

I can only assume you ask for elevation in case the user wants to make it run as a system service, but to be UAC compliant you don't ask for elevation until the user is about to do the thing that requires elevation.

 

In a correctly configured user environment, mediabrowser3 gets installed to the administrator's user folder and not the actual person's user folder. This is undesired behavior, because the regular user then cannot start mediabrowser3 server, since all the shortcuts and executables are locked away in the admin folder.

 

You need to just install to program files like any other normal program, or don't elevate the installer. Why do you not install to program files in the first place? If you really must continue using the user folder to store the program (which is just....wrong, and I'd like to know why you do this), then you need to figure out another  way to run it as a system service.

 

thanks.

 

Link to comment
Share on other sites

We require elevation in order to set firewall rules so the server can operate properly.

 

We install to the user folder because our automatic update routines would not work if we went into Program Files (or any other area).

Link to comment
Share on other sites

There is proper procedure for adding firewall exceptions- the firewall prompt can elevate itself, you don't need to do that.

 

Elevating the installer then installing to the user folder is causing issues in a properly set up user environment. I'll explain.

 

Like any linux system, windows implemented UAC for privilege separation. For that to work, you need to separate the privileges- by creating one admin account and one regular account. Otherwise UAC is pointless. In my case, my user account is Link and my admin account is root.

 

When installing the your server, it asks for elevation then installs itself into users\root, where users\link can not access it. I was able to get the user Link to start the server after fooling around a bit (and it even installed itself into users\link without the installer somehow). It works perfectly fine without admin privs.

 

So please, correct the installation procedure so that it does not ask for elevation. If you're really having trouble getting the firewall permissions in, only ask for elevation to do that, not to install.

Edited by Link
  • Like 1
Link to comment
Share on other sites

It actually has nothing to do with the firewall. It's the automatic update issue that Ebr mentioned.

 

Running the server using  your kind of setup is currently a known issue for us, and something we will be working to improve. However, if you're going to tell us what we're doing wrong, maybe you should instead tell us what we can do better. I promise you, we're not bafoons. All of the issues you mention are things we've worked through already, but if we were to move to the admin folder or program files we would lose automated update capabilities.

  • Like 1
Link to comment
Share on other sites

Is it Pismo then, that we still require elevation for on the server?  We have removed the elevation from MBT but there was a reason we left it in the server and I can't recall at the moment exactly what it was.

Link to comment
Share on other sites

Sorry if I came off annoyed- usually when I bring up UAC compliance I am not well received. Many developers seem to have UAC completely disabled and run full admin accounts all the time, and are hostile/dismissive when I bring up that their programs don't work with UAC.

 

As far as automatic updates go, in my setup it's still a little rocky. It asks for elevation, I think I rejected it, the installer crashed, but the next time I started the server it's up to date.

Link to comment
Share on other sites

That is due to the fact that you installed into the admin directory but run it out of another user, I believe.

Link to comment
Share on other sites

There are two separate elevation requests - pismo install, firewall authorization. Despite your claim that the OS will popup a firewall request - yes, it should, but it does not always occur.

 

However - we only elevate those specific tasks and not the entire application or installer. At least the installer shouldn't be elevated, right Ebr?

Link to comment
Share on other sites

Elevating the entire installer was a strategy we employed to minimize the user interruptions during install.  We were hoping for pretty much zero interruptions but couldn't achieve that so we tried for just one.

 

If we don't feel the elevation is necessary anymore, I can remove it.  The server is the only component that still has it (MBT does not).

Link to comment
Share on other sites

That is due to the fact that you installed into the admin directory but run it out of another user, I believe.

 

 

This might be the result of running the update as a normal user, but the binaries did end up in my regular user folder without me putting them there.

 

Edit- you're probably right. I just tried it out on my other computer (the one related to my other topic... there were no useful logs unfortunately). It started, updated, and restarted, without asking for elevation or crashing.

Edited by Link
Link to comment
Share on other sites

  • 4 months later...

Where are we with this? I stopped using mediabrowser for a while, and recently reinstalled it again, noting that elevation has not gone anywhere, though there still doesn't appear to be a reason to have it; it's not needed for the general binary, and if you still have some weird distrust issues with using windows' firewall prompts, couldn't you just have a single elevation prompt midway through the install for that, so the directories are at least handled correctly?

 

Moreover, the last two updates just silently fail without admin elevation, and I've had to manually install, guess which files were updated, and manually move them to the correct location.

Edited by Link
Link to comment
Share on other sites

There was a bug in the updater that was fixed that might be the problem you're describing, although i'd need to see the server and install log files to verify.

Link to comment
Share on other sites

Hmm, I uninstalled the server, and tried to install both the stable and beta of the server cleanly.

 

Both crash if denied UAC elevation.

 

Problem signature:
  Problem Event Name: CLR20r3
  Problem Signature 01: MediaBrowser.Server.Installer
  Problem Signature 02: 1.0.0.0
  Problem Signature 03: 524af17a
  Problem Signature 04: System
  Problem Signature 05: 4.0.30319.34003
  Problem Signature 06: 522ec39f
  Problem Signature 07: 3fed
  Problem Signature 08: 2a9
  Problem Signature 09: System.Windows.Markup.XamlParse
  OS Version: 6.3.9600.2.0.0.256.103
  Locale ID: 1033
  Additional Information 1: 5861
  Additional Information 2: 5861822e1919d7c014bbb064c64908b2
  Additional Information 3: d1d9
  Additional Information 4: d1d94a13d3609d6b740644c12508f581

 

 

Not sure why that is, but when run with sandboxie and denied UAC, it doesn't crash, it just says "program cannot start", and gives this logfile.

PLATFORM VERSION INFO
	Windows 			: 6.2.9200.0 (Win32NT)
	Common Language Runtime 	: 4.0.30319.34014
	System.Deployment.dll 		: 4.0.30319.33440 built by: FX45W81RTMREL
	clr.dll 			: 4.0.30319.34014 built by: FX45W81RTMGDR
	dfdll.dll 			: 4.0.30319.33440 built by: FX45W81RTMREL
	dfshim.dll 			: 6.3.9600.16384 (winblue_rtm.130821-1623)

SOURCES
	Deployment url			: http://www.mb3admin.com/downloads/beta/server/MediaBrowser.Server.Installer.application
						Server		: cloudflare-nginx

IDENTITIES
	Deployment Identity		: MediaBrowser.Server.Installer.application, Version=3.0.1.19, Culture=neutral, PublicKeyToken=4b9d5f30d771bc4d, processorArchitecture=x86

APPLICATION SUMMARY
	* Online only application.

ERROR SUMMARY
	Below is a summary of the errors, details of these errors are listed later in the log.
	* Activation of http://www.mb3admin.com/downloads/beta/server/MediaBrowser.Server.Installer.application resulted in exception. Following failure messages were detected:
		+ The operation was canceled by the user. (Exception from HRESULT: 0x800704C7)

COMPONENT STORE TRANSACTION FAILURE SUMMARY
	No transaction error was detected.

WARNINGS
	There were no warnings during this operation.

OPERATION PROGRESS STATUS
	* [14/04/12 21:09:22] : Activation of http://www.mb3admin.com/downloads/beta/server/MediaBrowser.Server.Installer.application has started.
	* [14/04/12 21:09:24] : Processing of deployment manifest has successfully completed.

ERROR DETAILS
	Following errors were detected during this operation.
	* [14/04/12 21:09:27] System.Runtime.InteropServices.COMException
		- The operation was canceled by the user. (Exception from HRESULT: 0x800704C7)
		- Source: System.Deployment
		- Stack trace:
			at System.Deployment.Application.NativeMethods.CorLaunchApplication(UInt32 hostType, String applicationFullName, Int32 manifestPathsCount, String[] manifestPaths, Int32 activationDataCount, String[] activationData, PROCESS_INFORMATION processInformation)
			at System.Deployment.Application.ComponentStore.ActivateApplication(DefinitionAppId appId, String activationParameter, Boolean useActivationParameter)
			at System.Deployment.Application.SubscriptionStore.ActivateApplication(DefinitionAppId appId, String activationParameter, Boolean useActivationParameter)
			at System.Deployment.Application.ApplicationActivator.Activate(DefinitionAppId appId, AssemblyManifest appManifest, String activationParameter, Boolean useActivationParameter)
			at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
			at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)

COMPONENT STORE TRANSACTION DETAILS
	* Transaction at [14/04/12 21:09:24]
		+ System.Deployment.Internal.Isolation.StoreOperationSetDeploymentMetadata
			- Status: Set
			- HRESULT: 0x0
		+ System.Deployment.Internal.Isolation.StoreTransactionOperationType (27)
			- HRESULT: 0x0


Link to comment
Share on other sites

That's not what I was referring to. We should clean up the crash on uac denial, but you'll still need it to complete the installation.

Link to comment
Share on other sites

Why? When the entire installer is elevated, it installs mediabrowser to the wrong folder- one inaccessible by users.

 

You can 't both elevate the entire installer AND install to the user folder- these are mutually exclusive things. If there are steps in the installer that need admin elevation, have it spawn a sub process that asks for elevation.

 

edit- So I installed it, moved it out of the admin's user folder into my folder where it should have been installed to. The server is asking for elevation upon every start now, but the process is not owned by admin user, and it works if I deny the UAC prompt.... Why is it asking for elevation?

Edited by Link
Link to comment
Share on other sites

Right now we chose to keep installing the server to the admin user account because we don't want people installing multiple copies of the server on the same machine.

 

This appears to be working for 99% of people.

Link to comment
Share on other sites

Don't abuse the admin privileges to inelegantly try and prevent user error.

 

There are so many more elegant solutions than just blatantly undermining the security model....

 

Let the user choose where to install it.

Install to c:\ by default.

Install to program files by default.

Don't ask for elevation, have the installer detect if mediabrowser had ever been installed on the machine (via registry) and warn them about it.

If you thought about it for a minute, I'm sure you could come up with a dozen other solutions.

 

99% of users don't actually know or are dismissive of the correct user/admin setup, because the windows installer holds your hand through the setup process but ends as soon as the admin user is created. Thus, Windows has a culture of bad security practices. Don't encourage it.

 

Linux however does not have this misguided culture- if you misuse the root account under linux like you are on windows, it won't be just me whining.

 

By now I probably seem a little annoyed, and I apologize for that, but so far instead of coming up with solutions you've just dismissively given me excuses for why you've opted to butcher the existing security model.

Link to comment
Share on other sites

Linux installs will use an entirely different model.

 

If we attempted to install to any of the other places you suggested, we would then have to request elevation.  Plus we would run into elevation problems with our auto update routines which is the real reason we are installing where we are.  I don't like the fact that we have to install to the users directory, but there is no other way to guarantee that our auto update features will work and that is the most important factor in the equation right now.

 

When and if it becomes a higher priority, we can always look for other solutions, but, given the resources we have and the problems we encountered, we are using the best solution at the moment.  We didn't just blindly arrive at this situation.

Link to comment
Share on other sites

JeremyFr79

I have an idea! why not make server require a Server OS for install thus making it so everyone has to have a dedicated server to run the server on and then you wouldn't have to worry about UAC at all?  Sorry had to add my sarcastic comment here.  I guess what irritates me personally about this thread is the person is complaining about a user/admin roles, but fails to utilize a server/client role via seperate machines.  So to the OP if you fail to do one thing properly, why complain about someone else not doing something completely properly???  Guess this thread and the OP's responses just rub me the wrong way.  I'll take my grumpy grouchy self out of this thread now lol.

Edited by JeremyFr79
Link to comment
Share on other sites

If we attempted to install to any of the other places you suggested, we would then have to request elevation.

So... you request elevation when you don't need it instead?

 

Plus we would run into elevation problems with our auto update routines which is the real reason we are installing where we are.

When and if it becomes a higher priority, we can always look for other solutions, but, given the resources we have and the problems we encountered, we are using the best solution at the moment. We didn't just blindly arrive at this situation.

Ok, this is understandable. You want the remote interface to just work. I get it. But nothing you have said so far excludes the following solution:

 

User runs the installer. Installer installs to the user folder. When, and only when it is time to deal with the firewall manually, request elevation.

 

This is simple and easy to do, it will eliminate fundamental security concerns, and it will bring mediabrowser to full UAC compliance. Unless I'm missing something, this doesn't conflict with any of your given statements.

Link to comment
Share on other sites

 

But UAC exists on the newer MS server OSes too ;)

 

EBR is nice.  He can't say nobody cares.

 

MS tried to force everyone to correctly separate user and admin roles and their customer base loathed it.  The current install process works best for the vast majority of Windows users.  Users that don't like that model are likely not using Windows so the Linux installer having a different process makes sense.

 

 

Just fyi, most viruses and exploits that infect Windows operating systems are only successful because the vast majority of Windows computers have an admin user, and only an admin user... All those flash vulnerabilities wouldn't do much at all if the infected users weren't running their browser with enough privileges to make changes to the entire system! I like Windows, and I like common sense. The Windows consumer base loathes it because they're accustomed to years of bad habits. This should and will eventually change.

Link to comment
Share on other sites

Deathsquirrel

But UAC exists on the newer MS server OSes too ;)

 

EBR is nice.  He can't say nobody cares.

 

MS tried to force everyone to correctly separate user and admin roles and their customer base loathed it.  The current install process works best for the vast majority of Windows users.  Users that don't like that model are likely not using Windows so the Linux installer having a different process makes sense.

Link to comment
Share on other sites

ronvp

   

 

Just fyi, most viruses and exploits that infect Windows operating systems are only successful because the vast majority of Windows computers have an admin user, and only an admin user... All those flash vulnerabilities wouldn't do much at all if the infected users weren't running their browser with enough privileges to make changes to the entire system! I like Windows, and I like common sense. The Windows consumer base loathes it because they're accustomed to years of bad habits. This should and will eventually change.

That argument is just old and no longer accurate.. it may have correct in the old days, but not today.. the user/admin discussion is valid/needed only on a corporate environment where the risk of a company wide issues is just to large and we can call IT to fix install and update issues.. For MB users, who are mostly home users, it works fine as is and the current approach does not elevate the security risk in any way provided the user has a proper firewall and anti virus program running..

 

My opinion is that UAC compliant install apps are important, but not critical to the security of a home users PC.. The majority of Today's security risks are not associated with windows based home PC's running/installing programs with a single admin account

Link to comment
Share on other sites

That argument is just old and no longer accurate.. it may have correct in the old days, but not today.. the user/admin discussion is valid/needed only on a corporate environment where the risk of a company wide issues is just to large and we can call IT to fix install and update issues.. For MB users, who are mostly home users, it works fine as is and the current approach does not elevate the security risk in any way provided the user has a proper firewall and anti virus program running..

 

My opinion is that UAC compliant install apps are important, but not critical to the security of a home users PC.. The majority of Today's security risks are not associated with windows based home PC's running/installing programs with a single admin account

I'm not going to offer a full rebuttal on your opinion of the effectiveness of user/admin separation because I fear that discussion will overshadow the main purpose of this thread, however I will make these comments:

 

Privilege separation wouldn't be held sacred in the linux community if it weren't important.

 

Saying "it's not critical for the average user" may be true in a sense, but the argument is pointless and leads to no constructive discussion. Everyone should be encouraged to have better security habits. End of story. What you choose for yourself is your business, but it is important for the collective whole to take steps to better security, no matter how small.

 

Think of privilege separation and general security like car seat belts- you should wear a seat belt every time you get in a car, and you may drive for years without ever having needed to wear it. But an accident only needs to happen once.

 

The repercussions in computers are of course not as physically drastic, but the point is you never know when something might sneak onto your computer. For every infection that manages to circumvent privilege separation, a thousand would be stopped. Just because a virus might bypass your immune system, you wouldn't just shut the first line of defense down. By practicing basic security- maybe you won't be part of a botnet. Maybe you'll be passed over by a program looking for weak systems to infiltrate. Many possibilities.

 

However, I didn't start this thread to defend basic practices, so I'll be sticking to the topic from now on :)

Edited by Link
Link to comment
Share on other sites

So... you request elevation when you don't need it instead?

 

 

Ok, this is understandable. You want the remote interface to just work. I get it. But nothing you have said so far excludes the following solution:

 

User runs the installer. Installer installs to the user folder. When, and only when it is time to deal with the firewall manually, request elevation.

 

This is simple and easy to do, it will eliminate fundamental security concerns, and it will bring mediabrowser to full UAC compliance. Unless I'm missing something, this doesn't conflict with any of your given statements.

 

No,we are pre-preemptively requesting what we know we will need.  

 

We need to install the program in a single location on any given machine.  If we did what you suggested, the normal user (who doesn't know much or even really care about this security model) could easily end up installing the server multiple times on the same machine and not know it and run into all kinds of problems down the road.

 

Now you ask why not then go into C or Program files?  Well, again this is because of the need to run silent auto updates and be sure they will succeed.  The only way we have found to be sure of this is to have our program files under the user directory. This is why ClickOnce apps do the exact same thing.

 

We have selected the least of the evils that works the best for 99% of our user base.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...