service install is Vista only??

Sorry for the bump, but I couldn't find any definite answer to address Epsilon's concerns.

To be frank, I really don't like the idea of Steam having a service running on my system. The reason alfred gave us in this thread:

Originally Posted by Alfred

Certain operations under Vista now need a service for them to work

Is far to vague for my liking, I would like to know:
1) What operations exactly need the service to work?
2) Once this beta is gold and it is pushed to all clients, will we still have the option of not installing the service?
3) What is the reaction from the Steam developers to the security concerns raised in this thread (by Epsilon)?

I would like to close off this post by saying that I share the concerns Epsilon raises about the need of a system service to implement Steam, and I would like not to install it (there is no 'but what if', I do not want to run a system service for Steam).

[Varsity]

All the service does is move some functions out of the client that would otherwise cause a UAC prompt. There's nothing new, that I know of.

The service only runs when Steam runs. All in all, there is no reason at all to be worried about it. Unless you have a great emotional attachment to Valve's coding practices.

[Epsilon]

It's certainly not an ideal solution - ideally, there should be elevation only when an action is performed that would require admin rights, like updates or installs, then the elevated process should go away again when that's done.

Unfortuantly, that requires some up-front investment to work out what really needs admin rights and what doesn't. Like at the moment Steam writes a bunch of config data (like the clientregistry.blob) into the Steam folder under Program Files. This is incorrect behaviour. It should be under C:\Documents and Settings under XP, and C:\Users on Vista.

Instead they've chosen the easy option, which is to move a bunch of Steam code out to a service. If they went to the trouble of doing it properly, sure, you'd get a few UAC prompts now and again when Steam wants to update, but this is the way it should be, and it would also help running Steam under a limited user account on XP. You'd need an admin account to install and update, but it would work fine between those times.

But never mind! Hopefully from now on applications will not be able to ride totally roughshod over best practices.

I am running Steam right now under Vista with UAC enabled, without the service, and the only issue I have noticed is that Steam crashes when it tries to scan my hardware in the user survey, because it is not allowed to. The fact that an error in the survey takes the whole application down with it doesn't really give me any confidence in Valve's coding practices, but that aside:
Right now everything works as it should (just like in XP), I can install games, update games, update steam, buy games online, talk to friends, even use the voice chat. There is only one UAC screen I have ever seen on steam, which is when I tried installing the Bioshock demo and it wanted to install Visual C++ runtimes (which I distrusted, and I clicked no, of course).

So if there is no action in Steam that I take, why would I need an additional component to 'run steam properly'? What is this improper stuff that is not working?

Also, if it is just to 'circumvent' the UAC screens ... if I wanted applications to circumvent UAC, I would just disable it, or run the applications using Administrative rights. But I would like to know when an application does something that requires Administrative rights, and I would like the power to say 'no, you can't do that on my system'. I have that with UAC, so I'm not going to allow anything to circumvent that.

So I'll just reiterate my earlier questions:
1) What does not work without the service?
2) Will we have the option of not installing the service when it is released?
3) What do the Steam developers (or architects) think about these concerns?

[p5ychokilla]

Originally Posted by Epsilon

The point of UAC is to actually enforce the Windows application development guidelines, so that application developers from here on in will actually have to develop their applications properly. I.e. not writing application configuration into Program Files. Not writing into Program Files in general. Putting per-user configuration into the user's Appdata folder. That kind of thing.

A properly written application will prompt you with UAC only when 1) It's installing, 2) It's going to change a system setting, 3) It's updating itself 4) When you're uninstalling it.

But instead of making Steam comply with the guidelines, Valve just install a service component which runs with administrator priviledges so they can continue to behave badly.

And it's bad behaviour because generally you want as few things on your system as possible running with admin rights because it reduces your attack surface area. It's not foolproof, nothing is. But proper security is about defense in depth.

The Steam service is risky in that sense because there's some method by which the Steam client (running with limited priviledge) is contacting the service (running with admin rights) and that's a potential attack vector by which some code running with low priviledge could exploit a possible vulnerability in that interface to execute code with higher priviledge and do whatever it likes to your system. A lot of the opposition to UAC is that power users think it somehow runs roughshod over their rights to use their own systems. Actually, with UAC on you have more control over your system because 3rd party apps can't change the configuration of your system with impunity.

The point of UAC is to make everything digitally signed so Microsoft can make more money by forcing small companies to pay a fortune just to get a stamp, then they can buy them out and take over the world....muahahahah

[Epsilon]

Stuff's generally digitially signed by companies like Verisign. Anyways, I write programs in my spare time and none of them have yet needed either a UAC prompt to run, or a digital signature.

Anyways, all of the Steam files are already digitally signed.

[Krid]

Originally Posted by Epsilon

I.e. not writing application configuration into Program Files. Not writing into Program Files in general. Putting per-user configuration into the user's Appdata folder. That kind of thing.

...Because storing data in a monolithic database is just SO much better than storing configuration data in a program's folder. It's slower, it's no more reliable, it wastes system resources, it certainly doesn't save any drive space, it makes it easier for malware to spy on users, it makes it easier for malware to hide, it breaks application mobility, and there are countless other problems... But there has to be SOME reason to do it, right? I mean, aside from the network management features that more than 75% of the installed userbase is incapable of using as a result of using the Home version, and that only a scant few corporate installs bother to use. Even then, there are alternate ways to do those tasks that are no harder to accomplish.

Forcing non-system programs to use the registry is a stupid idea, not that the registry was all that great of an idea to begin with. I suppose that is where our respective ideas of "proper practices" differ.

[Epsilon]

I didn't say anything about the Registry. Appdata is a regular filesystem folder.

I agree with you on the registry, the less it's used the better. I guess it looked like a good idea at the time, but since even Microsoft have realised it was a bad plan. It's one of those pieces of useless cruft Windows is laden with because removing it would do more damage than it would solve.

Anyways, putting Steam's per-user data into something like the clientregistry.blob file in AppData could mean it be taken out of the registry, where a big lump of Steam config is stored in HKEY_CURRENT_USER\Software\Valve\Steam.

[Krid]

Ah, sorry, I misread that. I blame lack of sleep. ^^;;

It's somewhat comforting that Microsoft has started to pay attention to the good design decisions that were made for *nix type systems a few decades ago.
Somewhat. :/

[Epsilon]

Heh, s'alright, I know the feeling of the sleep deprivation

The good design decisions have been around since at least Windows 2000. Problem is the demon of backwards compatibility. To ensure 9x era programs would keep working when people upgraded to XP, all the old ugly ways of doing things had to still work, but the intention was that new software would be developed to the new guidelines.

Fat chance, new software is still doing the wrong thing. Like games shouldn't be writing out saved games to C:\Program Files\WhateverTheGameIs\ ! It's sick, and it's wrong, and it shouldn't be allowed. It's like Word's default save location being in the same folder as winword.exe, it's totally nonsensical.

Anyways, UAC is half security feature, half big heavy stick to beat developers with until they start doing stuff right. Alas, instead of doing stuff right, we're getting a service install to allow all the bad old behaviour.

So yeh, it's not like Microsoft is stupid or anything, somehow failing all these years to have a security model as good as *nix, they're just hamstrung by rubbish third-party code. Because if all these badly-written applications break after Microsoft releases a new OS, who gets the blame? Microsoft of course, for writing a "rubbish OS", even if it's technically superior to the old one.

[jmccaskey]

Valve doesn't control all of the code for all of the games in Steam. It's nice to say "everyone should just make their code work like Vista wants it to", but we can't do that when we are shipping a game created by someone else four years ago that is no longer actively developed.

That game will most likely expect to be able to write to your "Program Files" directory. It will most likely require writing registry keys in HKEY_LOCAL_MACHINE instead of HKEY_CURRENT_USER (needs Admin privileges) both at install time and at run-time. Furthermore, placing all your configuration and data files inside your user folder isn't a good model for Steam. We are distributing large amounts of content via Steam that is intended to be shared by users across the machine. The directory layout in Vista is not really designed to support content distribution systems like this, it's designed for every single game using a seperate standard .msi installer. Vista's user model also isn't designed to support code like VAC. VAC is doing low level work to check out other running processes memory space and find cheats, some of the work it does can't occur without escalating privileges. In this respect it acts much more like an Antivirus program than anything else. And guess what? All your antivirus software is installing services isn't it? Why aren't you alarmed at that? You probably also know that PunkBuster and other similar software already does the same thing and installs a service in order to get it's job done. Yes, before we did every single one of these operations the Steam process itself could try to escalate its permissions and you as a user would be warned and asked to allow it, but the number of warnings would be painfully large and would be confusing to most users. You also can't actually escalate within a running process, you must spawn a new process because you must request admin priveleges when the process starts. Starting lots of processes for small actions can be costly when it comes to performance as well as annoying as it means many individual UAC prompts. We don't like that option. Instead we have the Steam service, you install it once and you tell Vista at that time that you trust Steam to install this piece of signed code.

Security wise all of the service executables are signed code and have a very limited set of abilities. By installing the service you are letting Steam perform some administrative operations on your machine. However, due to the security model built into the service and due to the fact that the code is signed you are not opening up your machine for just any piece of code to abuse the service and hack your machine. Letting Steam do this is just like letting a .msi installer for a game have Administrative privileges at run-time or allowing your Antivirus software to install a service. By using the service we are just saying "you only have to authorize us once", instead of causing you to be constantly prompted each time you install or run many games.

Ultimately its your choice, we cannot force you to install the service. Vista will always warn you that Steam is trying to escalate privileges when the service installation occurs. If you are unhappy with it, then don't install it. However, if you don't install it Steam and many games will be broken in subtle ways and we can't gurantee things will work as expected. The service is going to be an integral part of Steam on Vista and by choosing not to install it you are choosing to prevent your Steam installation being fully functional.

Thank you for that post, that clears up almost everything for me. What I'm still wondering is if I choose to not install the service, will I be UAC prompted if elevation is required? Or will steam silently fail the task?

[jmccaskey]

Originally Posted by keenriser

Thank you for that post, that clears up almost everything for me. What I'm still wondering is if I choose to not install the service, will I be UAC prompted if elevation is required? Or will steam silently fail the task?

Things will fail, sometimes silenty, sometimes not, but things will be broken.