To view parent comment, click here.
To read all comments associated with this story, please click here.
Well, how about how the Linux desktops do it (Gnome as well as KDE). They are TWO different desktops and manage to have the same menu entries no matter if you log into a Gnome session or a KDE session.
Additionally there are system-wide setings for the Start menu (changeable by root) and user-specific changes to that system-wide settings.
Therefore, when root installs a new program, the entry is made to the system-wide settings, and as no modification entry is in the user-specific setting, the new program is displayed.
It is very easy and works well. The same is done with mime-type settings (which kind of file to be opened with which application).
Quite the opposite is the reality. In the company I work for we calculate stresses and safety factors of engine parts with FiniteElement software. We need to know which machine is under which load when we start another number-crunching job. Needing admin rights just to get the information is ridiculus. I agree that priority enhancing ones process or priority changes to an other users process require admin rights, but not for getting information. Security by obscurity does not work, so why even try that approach. If the system becomes insecure when somebody finds out about it's load, network, memory and disk status, it's security is not worth much.
I agree that there are some reasonable scenarios where you'd want someone who's non-admin to be able to access performance statistics. Thus there exist two built-in groups on my Vista Business installation: "Performance Log Users" and "Performance Monitor Users." I haven't tested those myself, but based on their names and description strings I believe that these groups give you what you want: the ability to grant non-admin users the right to view perf data for the whole machine.
First of all, I don't exactly see what you consider to be a flaw (or how you'd design it differently). Second, I don't see your implementation of a time machine that I could use to fix flaws 10 years ago before apps took reasonable dependencies on whatever design decision you're complaining about.
On Vista Business, maybe, on Server 2k8, definately. But Vista Home/Ultimate?
If you want to grant people that right, there are ways (see my earlier response).
On the Home vs. Business distinction, I think it's general practice to keep the SKUs of an OS as similar in shared configuration as possible so that it's clear what should happen when you move from one SKU to the other (like through Windows Anytime Upgrade).
Maybe the people who own that MMC snap-in will make some tweaks to make it accessible securely to less-privileged users, but that was apparently not a priority so far (it's far more important to have something which you can later tweak given the feedback of the first version than to not have that thing at all).






Member since:
2006-01-02
Screwing around with the Start Menu engenders UAC prompts because large parts of the start menu are stored on a system-wide basis. I did a thought experiment about how one would implement this on a per-user basis with a shared system view, but I couldn't think of anything great because you'd have to merge any changes to the global start menu groups into a potentially changed set of per-use groups. I just tend to use the start menu search feature and igore the particulars of my start menu's organization.
On the reliability and perf monitor, I think it should require admin access because the program needs information about the specific Disk, CPU, and Network activity of everything on the system. Allowing untrusted users to see this information would be classiied as an Information Disclosure Vulnerability.