From: Chris Devers Date: 20:22 on 07 Apr 2005 Subject: Windows permissions and painfully misimplemented multi-user system 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...
From: Chris Devers Date: 17:31 on 08 Apr 2005 Subject: Re: Windows permissions and painfully misimplemented multi-user system On Thu, 7 Apr 2005, Chris Devers wrote: > 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. Wow, they listen! <http://www.pcworld.com/resource/printable/article/0,aid,120314,00.asp>; <http://not-it.slashdot.org/article.pl?sid=05/04/08/147237&threshold=5>; Maybe. We'll see...
From: Darrell Fuhriman Date: 17:39 on 08 Apr 2005 Subject: Re: Windows permissions and painfully misimplemented multi-user system On Fri, Apr 08, 2005 at 12:31:12PM -0400, Chris Devers wrote: > Wow, they listen! Sometimes the clue escapes at Microsoft. Now if only Apple could do the same to its developers. As near as I can tell, Apple makes it pretty easy to drag and drop an application to install it, but for some damn reason some vendors insist on not doing that. Apple needs to smack them around a bit. Darrell
From: Michael G Schwern Date: 19:06 on 08 Apr 2005 Subject: Re: Windows permissions and painfully misimplemented multi-user system On Fri, Apr 08, 2005 at 09:39:00AM -0700, Darrell Fuhriman wrote: > Now if only Apple could do the same to its developers. As near > as I can tell, Apple makes it pretty easy to drag and drop an > application to install it, but for some damn reason some vendors > insist on not doing that. > > Apple needs to smack them around a bit. Case in point. NeoOffice, OpenOffice with a splash of Aqua. Why does it need a .pkg installer?! Looking inside /Library/Receipts/NeoOfficeJ.pkg/Contents/Resources I can use lsbom to see that all installed files went into a nice, neat NeoOffice.app directory in /Applications. The only installation logic is to check that basic BSD commands (ask, cat, chmod, chown...) are all there. Why NeoOffice needs these is beyond me. Its a 340 meg app, you'd think they could include a function to cat a file. Why it doesn't trust these files are shipped with OS X is beyond me. Why, if it does really need them, it doesn't just ship with these trivial binaries is beyond me. Maybe there's a plan to ship NeoOffice updates instead of whole release versions, dunno. I just hate it.
From: Michael G Schwern Date: 19:18 on 08 Apr 2005 Subject: Re: Windows permissions and painfully misimplemented multi-user system On Fri, Apr 08, 2005 at 12:31:12PM -0400, Chris Devers wrote: > Wow, they listen! > > <http://www.pcworld.com/resource/printable/article/0,aid,120314,00.asp>; > <http://not-it.slashdot.org/article.pl?sid=05/04/08/147237&threshold=5>; > > Maybe. We'll see... Microsoft claims that LUA will make life tougher for hackers and virus writers by limiting access to administrator permissions on Windows systems. Place your bets, folks. Future headline: "Microsoft sues lua.org for trademark infringment". Widely accepted within the software development community, least permissions has often been overlooked in recent years as operating system and application software companies have worked to make using software easier I hate software technology writers, particularly ones in trade rags like PC World where the universe stops at C:\. Overlooked in recent years, except by legions of screaming Unix sysadmins and security experts! NEWS FLASH! MICROSOFT SLAPS TLA ONTO OBVIOUS SECURITY POLICY! CLAIMS THEY INVENTED IT! Other changes will allow developers to create per-user installations of applications, with user-specific settings saved in the My Programs folder, rather than a globally accessible program files directory that requires administrative permissions to change, according to documents and presentations on Microsoft's Web page. Welcome to 1979, Microsoft. Glad you could make it.
Generated at 10:26 on 16 Apr 2008 by mariachi