Windows permissions and painfully misimplemented multi-user system

[prev] [thread] [next] [lurker] [Date index for 2005/04/07]

From: Chris Devers
Subject: Windows permissions and painfully misimplemented multi-user system
Date: 20:22 on 07 Apr 2005
Ghod do I love installing applications on Windows for new hires. 

In a better world, this would be no big deal. Install the OS, set us 
basic system settings, create accounts &/or attach to Samba domain, 
install standard applications, deploy.

But no, the application installs are rarely that straightforward.

Some require an administrator account to install, because they need to 
vomit random files and folders all over <C:\Program Files> and possibly 
<C:\Documents and Settings>. 

Some do not require an administrator account to install, because they 
just need to vomit random files and folders all over <C:\Program Files> 
and possibly <C:\Documents and Settings>.

Spot the inconsistency thus far.

The former tend to be available to all users of the system; the latter 
tend to just work for the account that installed it. Moreover, more 
often than not, the latter *don't work at all* for any account other 
than the one that installed it, which leads to all kinds of fun debug 
routines.

"What the hell? Palm Desktop worked when I gave you that computer, and 
so did AdAware. Why don't they work now? Why does everything else work?"

Sometimes, the "easy" fix is to go in, move any vomitus from my 
<C:\Documents and Settings\Administrator> tree over to the system-wide 
<C:\Documents and Settings\All Users> one, then follow this up with the 
equivalent of a `chmod -R 0777` to allow anyone to do anything to the 
settings and application files & folders, not because this makes sense, 
but because if I don't do it, the application doesn't work at all.

And of course, there's no rhyme or reason to this. As near as I can 
tell, it's all just down to the whim of the vendor's programming and QA 
departments, because Microsoft doesn't appear to enforce any kind of 
recognized coding or deployment policy about this.



My favorite crapware of an installation is probably Meetingmaker, which 
can only be installed by an account with administrator priviliges -- 
implying that it's going to be available system wide. But no, it only 
works for the account which installed it, so if your company policy is 
not to grant users admin accounts on their desktops, then they can't use 
the company groupware system. To fix this, you have to do the above 
mentioned "grant full access to this folder tree to all accounts", at 
which point anyone can tamper with it however the whim might please 
them. This may be risky, but if you don't do it that way, you just can't 
run it. Brilliant.

I'd be berating Meetingmaker for this bonedead setup, but they're hardly 
the only ones doing this sort of thing. Palm Desktop makes the same 
mistake. AdAware is "better", in that it will run for other users, but 
all the widgets are missing, so it might as well not work at all. Etc.


Haven't these people learned any lessons from other systems? All the 
endless wrangling over /bin /usr/bin /usr/local/bin /opt/bin /sw/bin etc 
is tedious, but the point being debated is valid & widely accepted -- 
there needs to be distinctions among vendor, system, and user installed 
programs -- and the approaches to the problem all more or less make the 
situation Less Bad.

Windows just ignores it all and has everything drop into a shared /bin 
directory, which you may or may not need magic pixie dust to alter. 

Maybe I just need some of the magic pixie dust that the stoner that 
settled on this was smoking at the time...



-- 
Chris Devers

Generated at 20:00 on 08 Apr 2005 by mariachi 0.52