Not UAC compliant and other compliance issues

[Link 3]

 

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.

I already understood the part about not installing to program files.

 

Your argument that a normal user "could easily end up installing the server multiple times on the same machine" holds no water. In the current setup you think you're catering to (every user is an admin), every user can install it, precisely because you chose to install to ApData. This is no different from a scenario where every user is a user. You haven't selected the least of the evils; you just have not thought this through. Realize that for the 99% of the user base you want to keep happy, this changes absolutely nothing. In 99% of your user base, every user is an admin. 99% of your user base has mediabrowser installed to their own AppData folder- this will not change for them when mediabrowser isn't elevated. 99% of your user base is susceptible to the very thing you claim to be protecting them against.

 

Now tell me again, why do you require elevation of the installer, as opposed to one substep thereof? You seem to be changing your answer as you go along... reviewing your earlier replies, the answer was simply "we opted to elevate the entire installer to reduce the number of UAC prompts".

Edited April 15, 2014 by Link

[Link 3]

I don't see how that would be possible.

 

When elevating in an environment with multiple admins, it selects by default to the last user you elevated to. Other admin accounts are listed, but the user needs to enter the credentials of any accounts not his/her own.

 

Unless you have somehow exploited UAC, you would have no control over who runs the installer, nor whose AppData folder mediabrowser is installed into. You could force the install to a specific appdata folder, because once elevated you can do anything, but you would have to seriously and permanently compromise the ACL permissions on the admin's user folder to accomplish this.

[Koleckai Silvestri 1150]

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.

C:\ isn't a protected directory. Installing into C:\MediaBrowser\Server would allow automatic upgrades to succeed and not need elevation. I install my games like World of Warcraft into C:\Games\ for this specific reason. I don't want to install them in User and don't want to worry about UAC for automatic updates. Have been updating the product every patch since 2007 this way.

[Link 3]

 

According to the research I did at the time, this isn't true.  My findings had the C: drive even more protected than Program Files.  That is why we went to the appdata area (like ClickOnce does).

 

But, honestly, this was a relatively low-priority area.  We needed something what was dead-easy and worked for 99% of the users and that is what we have.  If someone wants to join on and create a better way, I'm all for it.  We simply need to keep the requirements we currently have for "zero questions during install" and always works for automatic updates without the user needing to do anything else.  If the installation location were to change there would be an additional requirement of the update working for people who were installed to the old area without intervention and for it to clean up after itself.

 

Before we started installing to appdata, we had about 10% of our users have permission issues with updates.  Once we made that change, we haven't had a single issue and we haven't looked back since because we do have so many other more important things to work on.

Well, I just want you to know how important this is, and I hope you find time to correct it in the near future. I think we understand each other, so there's not much more I can do other than dispel any illusions you have about how it won't work and offer suggestions.

 

I have personally verified that I can create folders on the root of drive C:\ freely.

 

However, it doesn't actually matter if you put it in C:\ or Program files. You're asking for elevation. You can do anything. Use this to your advantage. You need only explicitly set the ACL permissions on the mediabrowser install folder for the users group.

 

 

The Steam client does exactly this, actually. Take a look http://i.imgur.com/lDkdZrW.png

 

Now, steam doesn't need elevation to install or remove games, which reside in the program files folder.

 

Sorry I didn't come up with the steam example sooner. It's perfectly possible to have autoupdate work out of program files. Or, install to C:\ProgramData. In fact if you install there, I don't think you'd even have to manually set the ACL, since that is accessible from userspace. Give that a test.

 

Either Program Files with adjusted ACLs or ProgramData will work for 100% of users. If that doesn't work then the user has other problems beyond the scope of your support forum.

 

Edit- be sure to install shortcuts to C:\ProgramData\Microsoft\Windows\Start Menu\Programs

This is the start menu folder all users share.

 

Edit2- Funnily enough, you seem to have had this idea before me, but arbitrarily not with the server.... http://i.imgur.com/H2R69vS.png

Edited April 16, 2014 by Link

[Deathsquirrel 741]

My job is to manage a technical support team for a business software provider.  A VERY big part of that job is managing priorities for customer issues.  Typically this is done a 1-5 scale with 1 being absolutely mission critical and 5 being 'we're humoring you here but yes, the word 'the' is misspelled on page 4 of the manual so we're logging it.'

 

Link, this is about a 12 on that scale.  They already told you the installer would require escalating permissions regardless.  You're complaining about WHEN it happens.

 

If you're a developer with expertise in building in installers and want to volunteer to work on the project talk to them about contributing those skills.  If not then clearly they've heard you and, barring additional community concern about this issue, this will be addressed about half an hour after the end of time.

 

From experience though, most users prefer the UAC prompts come at the start of the process because of the way the system sort of hangs when they come up.  It can be very confusing when it happens mid-install.

[ebr 14918]

C:\ isn't a protected directory. Installing into C:\MediaBrowser\Server would allow automatic upgrades to succeed and not need elevation. I install my games like World of Warcraft into C:\Games\ for this specific reason. I don't want to install them in User and don't want to worry about UAC for automatic updates. Have been updating the product every patch since 2007 this way.

 

According to the research I did at the time, this isn't true.  My findings had the C: drive even more protected than Program Files.  That is why we went to the appdata area (like ClickOnce does).

 

But, honestly, this was a relatively low-priority area.  We needed something what was dead-easy and worked for 99% of the users and that is what we have.  If someone wants to join on and create a better way, I'm all for it.  We simply need to keep the requirements we currently have for "zero questions during install" and always works for automatic updates without the user needing to do anything else.  If the installation location were to change there would be an additional requirement of the update working for people who were installed to the old area without intervention and for it to clean up after itself.

 

Before we started installing to appdata, we had about 10% of our users have permission issues with updates.  Once we made that change, we haven't had a single issue and we haven't looked back since because we do have so many other more important things to work on.

[ebr 14918]

 I already understood the part about not installing to program files.

 

Your argument that a normal user "could easily end up installing the server multiple times on the same machine" holds no water. In the current setup you think you're catering to (every user is an admin), every user can install it, precisely because you chose to install to ApData. This is no different from a scenario where every user is a user. You haven't selected the least of the evils; you just have not thought this through. Realize that for the 99% of the user base you want to keep happy, this changes absolutely nothing. In 99% of your user base, every user is an admin. 99% of your user base has mediabrowser installed to their own AppData folder- this will not change for them when mediabrowser isn't elevated. 99% of your user base is susceptible to the very thing you claim to be protecting them against.

 

Now tell me again, why do you require elevation of the installer, as opposed to one substep thereof? You seem to be changing your answer as you go along... reviewing your earlier replies, the answer was simply "we opted to elevate the entire installer to reduce the number of UAC prompts".

 

I'm pretty sure our elevation causes the server to be installed into the first admin user's account regardless of the level of the current user but, honestly, it has been a while so I'm not 100% on this.

[DGMayor 88]

 

I have personally verified that I can create folders on the root of drive C:\ freely.

 

 

What OS?  I'm pretty sure Windows 8 upped the security on the root of C by default.

[techywarrior 688]

My job is to manage a technical support team for a business software provider.  A VERY big part of that job is managing priorities for customer issues.  Typically this is done a 1-5 scale with 1 being absolutely mission critical and 5 being 'we're humoring you here but yes, the word 'the' is misspelled on page 4 of the manual so we're logging it.'

 

Link, this is about a 12 on that scale.  They already told you the installer would require escalating permissions regardless.  You're complaining about WHEN it happens.

 

If you're a developer with expertise in building in installers and want to volunteer to work on the project talk to them about contributing those skills.  If not then clearly they've heard you and, barring additional community concern about this issue, this will be addressed about half an hour after the end of time.

 

From experience though, most users prefer the UAC prompts come at the start of the process because of the way the system sort of hangs when they come up.  It can be very confusing when it happens mid-install.

 

I don't think that anything regarding the security of a system should be given a very low priority regardless of how insignificant you feel it is.

 

Link brought up a valid point/complaint. Ebr has heard it and responded. And so far I don't think that the thread has really becoming much more then a point/counter-point discussion.

 

As long as thing stay cordial then I think it should be continued. Perhaps Ebr and Luke don't change the installer, or perhaps Link finds/suggests a method that will work with the way MB3 needs to behave.

 

I think there have been a few things brought up by Ebr as to why they chose the method they have and now it's really up to someone else to see if all those conditions can be met while not circumventing or trivializing the UAC security.

 

My personal opinion is that if the program can be installed into a location where it doesn't require admin/elevated privileges to be updated then the UAC prompt should only appear when the firewall settings are about to be set. The installer can look for a registry key to see if it is installed in an existing location and prompt to notify. That should take care of the issues that have been brought up so far I believe. I don't know if those are the only issues tho but I remember at the very beginning of development when the location/installer was discussed and I for one wasn't in love with the choice but I also don't have the skill to write the installer, or contribute to that part of MB3.

[Link 3]

 

What OS?  I'm pretty sure Windows 8 upped the security on the root of C by default.

Apparently not. Fresh install of Windows 8.1 Pro x64, updated to update 1

 

There's nothing particularly worth protecting about the root of drive C:\... All the various windows folders have their own set of permissions, and there's nothing really significant about the actual root.

Edited April 16, 2014 by Link

[Koleckai Silvestri 1150]

I don't see how that would be possible. When elevating in an environment with multiple admins, it selects by default to the last user you elevated to. Other admin accounts are listed, but the user needs to enter the credentials of any accounts not his/her own. Unless you have somehow exploited UAC, you would have no control over who runs the installer, nor whose AppData folder mediabrowser is installed into. You could force the install to a specific appdata folder, because once elevated you can do anything, but you would have to seriously and permanently compromise the ACL permissions on the admin's user folder to accomplish this.

 

Most Windows computers probably have 1, maybe 2, accounts on their computer. I have two accounts on my computer. Wayne and "In Case of Emergency". The second is only a standard account. The other computers in the house each have one account for the person that they belong to. Half of them don't even have passwords.

 

I might be more diligent if I had a true server - client environment. Unfortunately, I don't and probably won't for a long time. I just wanted to make movies and television available to everyone in the house on any device they might have. I do realize that Windows has a hidden administrator account as well but I've not logged into that account since it actually mattered for anything.

 

So the big issue is the difference between a server - client environment and casual users who just want to watch movies without a lot of fuss.

[Link 3]

Most Windows computers probably have 1, maybe 2, accounts on their computer. I have two accounts on my computer. Wayne and "In Case of Emergency". The second is only a standard account. The other computers in the house each have one account for the person that they belong to. Half of them don't even have passwords.

 

I might be more diligent if I had a true server - client environment. Unfortunately, I don't and probably won't for a long time. I just wanted to make movies and television available to everyone in the house on any device they might have. I do realize that Windows has a hidden administrator account as well but I've not logged into that account since it actually mattered for anything.

 

So the big issue is the difference between a server - client environment and casual users who just want to watch movies without a lot of fuss.

You seem to fundamentally misunderstand.

 

If a computer has more than one user, and both users want to install mediabrowser, and both users are admin (which is very likely), then mediabrowser will be installed twice, which will lead to conflicts. This is true of how mediabrowser is currently implemented right now.

 

The changes I am proposing do not affect the casual user at all (unless we move to programfiles, which will only benefit the average user), and only serve to benefit the more security minded individuals like myself. The "big issue" is simply that mediabrowser currently is, as the topic indicates, not compliant with the security infrastructure in Windows. Because of the way the installer mishandles UAC, in order to use mediabrowser I must actually elevate a 3rd party file manager to manually move all of the files to the correct location.

 

The hidden administrator account is meant for system services and emergency recovery shells, not meant to be logged into or elevated to in average uses. A proper setup involves creating two accounts- I have created 'root' (like the linux root) for the admin account, and my standard account, 'Link'. When installing mediabrowser, UAC acts as a sort of secure RunAs, and I elevate to the root user where then mediabrowser itself becomes locked away in C:\Users\root\AppData

 

What I'm suggesting is that the installer don't elevate until the firewall step- which means when the standard user 'Link' installs it, it is installed to C:\Users\Link\AppData, then 'root' would only be called to update firewall rules. This does not change the behavior if you are already an admin- either way, it would be installed to C:\Users\Wayne, in your case.

 

One other suggestion is to just make C:\Program Files\Mediabrowser-Server writable by the Users group. Then the self updater will work, it will only be installed once, everyone is happy, etc, etc, and there will be no difference between your setup and my setup in the install process.

Edited April 16, 2014 by Link

[DGMayor 88]

  Apparently not. Fresh install of Windows 8.1 Pro x64, updated to update 1

 

There's nothing particularly worth protecting about the root of drive C:\... All the various windows folders have their own set of permissions, and there's nothing really significant about the actual root.

 

I realize we're quibbling over the root of C versus a folder off of C, but open up Notepad and try to save it to C..

 

 

I'm full admin, no UAC, yada yada..   You can copy files to C after a prompt, but...

 

[Link 3]

Right you are- interestingly a user's explorer can create folders without a prompt...

 

Moot point though- ACLs can be edited, and a folder can certainly be created in C:\ or C:\Program Files where the self updater will work.

Edited April 16, 2014 by Link

[ebr 14918]

Right you are- interestingly a user's explorer can create folders without a prompt...

 

Moot point though- ACLs can be edited, and a folder can certainly be created in C:\ or C:\Program Files where the self updater will work.

 

We, of course, used to do that when we went to program files and it didn't always work.  Maybe because of something the user did during the install, maybe because of holes in .net but there were definitely a number of people for which automatic updates did not work and it was due to the permissions not being set properly.  We never have that problem anymore and that was the most important thing.

 

As I said, if someone wants to contribute to make the install better in some way but still meet our other requirements, that would be lovely. Since the current system is working for our needs for 99.9% of the user base, I cannot make this a priority at this time.

[Link 3]

How about just asking the user where they want to install the program, like every other installer out there? Default to appdata if you like. Were I able to choose program files, UAC wouldn't be an issue.

 

You would have to reimplement the editing of ACLs if the directory is not in C:\Users

 

To make it simpler you could just implement a binary choice:

"Install to AppData? (Recommended)"

"Install to program files"

 

Have a short description of each.

And the editing of ACLs would only happen with the second choice, the first would work like it does now.

 

I'd be happy to come up with a proof of concept- what install script do you use?

[ebr 14918]

That suggestion breaks both of the requirements I stated for the installation:

 

1) That breaks the requirement of a "zero option/question install"

2) That would also make it possible for a user to install someplace where the server may not have rights to when it is running, thus breaking our automatic updates.

 

While this isn't a huge priority right now because it is working for us, we didn't just throw a dart and land in this situation.  We tried a lot of different things and this is what worked best.

[Link 3]

1) "Do you want to elevate" is a question, that demonstrably isn't needed, despite your insistence that the system firewall prompt is somehow unreliable, so you yourself already violate this principle. Why do you even have this arbitrary (and impossible) requirement? Surely if you expect your users to be able to use the server itself, you can expect of them to click the "next" button with default items checked. Or even just hide it as a "customize" install checkbox- many installers have no prompts unless you tick a box saying you want to customize the install. You cannot tell me this somehow is bad- that's ridiculous and I will not hear it.

 

2) No it wouldn't, if you bothered to read my post explaining how it would be done.

 

You say you tried editing the ACLs with some success in the past. Steam works via the same method- if it wasn't reliable for you, there was probably a reason for it, because *it works for steam*.

 

If it violates a core mechanic of the operating system I cannot agree that "it works the best", because by definition it does not work.

Edited April 17, 2014 by Link

[sydlexius 243]

That suggestion breaks both of the requirements I stated for the installation:

 

1) That breaks the requirement of a "zero option/question install"

2) That would also make it possible for a user to install someplace where the server may not have rights to when it is running, thus breaking our automatic updates.

 

While this isn't a huge priority right now because it is working for us, we didn't just throw a dart and land in this situation.  We tried a lot of different things and this is what worked best.

 

Perhaps you might consider moving away from ClickOnce installers to Windows Installer?  You'll be able to install to privileged folders (once elevated) and set apropriate ACLs.  This approach might make sense if you move to running MBServer as a proper service. Installed and running under a "luser" account, say, mb3user-$random, connecting to CIFS shares by way of impersonation, with all the necessary ACLs doled out at install time.  I recognize this would require massive functional, let alone factoral changes so I wouldn't expect to see it until triple-digit milestones   However this might be even more advantageous and easier to implement with MBT.  I'm a bit biased in that I'd like the ability as an app packager/desktop support guy and would love to be able to one day distribute MBT in organizations such as mine, silently and without a need for external network access.  Obviously MBS will need to tag along, and AD and/or LDAP authentication would still need to be bolted in.  At any rate, I'd love to see your application stack be a viable alternative to MS's Media Platform!

 

Sorry about the threadjack.  My perspective on conformance with UAC is that I regularly deal with deploying applications in an environment that has a high adoption rate of least-privileged access, either repackaging, scripting ACL changes, and where needed, creating application compatibility shims, or in many cases PowerBroker policies. UAC remains enabled at default settings.  On the one hand, this is a tremendous PITA, but on the other hand it has helped save a number of feet from being shot off!

[ebr 14918]

The only thing we use CO for now is pre-req installation and it works quite well for us.  I don't want to have to write and maintain that.  Notice how there are zero issues posted out here related to missing pre-requisite components for any of our packages?

 

Plus we are trying to share as much code base as we can because we have very limited resources.  Using an MSI makes that impossible.  Right now, MBC is the only component that uses an MSI and that is because it absolutely has to (the dll must go in the GAC).

 

Finally, I'll say this the last time - our installation procedure appears to be working for the vast majority of cases and it is relieving us of a lot of support burden that had existed in the past.  Therefore, it is not a priority for me to spend any time on it.  However, if another dev believes it can be improved without compromising any of our other goals, then I'm more than happy for them to contribute to it.