Jonathan C. Patschke
jp at celestrion.net
Thu Feb 23 19:05:09 CST 2006
On Thu, 23 Feb 2006, Charles Shannon Hendrix wrote:
> Even Microsoft installers seem to need admin privs. At least, they
> always fail for me if I don't have that.
Why is this a bad thing, again? Users can install most software that
has no reasonable need to writing outside of the profile root. I don't
run as an administrator on my sole 'doze box, and I only need to run
installers as a member of the Administrators group when I'm installing
something (like Office or Visual Studio) that has a reasonable
expectation of being used by anyone who would log into the system.
>> Members of the Power Users group typically have append access to the
>> shared Start Menu folder and to C:\Program Files.
> If it is append only, how do they remove a program, upgrade it, or
> create common data areas?
You have an administrator set rights appropriately.
> Like I said, UNIX has no installation system yet.
No, you just tend to have to copy libraries and files as root, or, as
most folks do (sudo gmake install), which can run any variety of Bad
> Good luck finding many that are like that though. Even some of the
> very latest games still insist on saving user data in the master
> install directory.
And this is Windows' fault exactly how?
>> Then this is a bug, not a design flaw.
> Yes it is a bug, but a bug caused by bad design. The design also makes
> it hard to fix things.
How do you reach that conclusion?
> Windows was never designed to be secure or multi-user, and attempts to
> graft that on have been poorly done.
Windows wasn't, but NT was (and was actually muti-user from the
beginning; even NT 3.1 systems have daemons (services) running under
accounts different from the logged-in user), and modern Windows is an
outgrowth of the NT project.
> And yes, part of UNIX's problem is also bad design. We learned a lot
> since its basic parts were created.
> Fortunately, people have done a better job fixing it and changing it
> than they have with Windows.
Which is why most Unixes don't have fine-grained rights (a la VMS), and
Windows does (check out the group policy editor sometime), right?
Security on Unix is a sham, and it's only exploited less than Windows
because your typical Unix user/admin tends to have several orders of
magnitude more sense and computing experience and your typical Windows
The concept of either being all-powerful or crippled was outdated the
minute Unix entered into use as a real timesharing environment, and it
hasn't really outgrown that. I can't, for instance, chown or chgrp most
device nodes to let people other than root manipulate devices on most
Unixes. Nor can I, for instance, let certain users bind to TCP or UDP
ports (even specific ports!) below 512, so pretty-much every daemon on
the system has to run as root at one point. Windows and VMS let the
administrator assign rights to that degree of granularity. Why not
>> kldload, insmod, or your system's local equivalent?
> Why would an installer system let those run?
How, exactly, do the typical Unix installer systems (pkgadd, rpm, sudo
gmake, inst, installp) prevent it? All of them allow shell scripts to
be run, and all of them run with full root privileges.
> What exactly forces the installer to modify a running kernel, or allow
> any arbitrary thing to happen?
What if you're installing a device driver? Or a program that needs a
kernel module (programs that needed /dev/random on SunOS 5.7 and earlier
come to mind)?
> When you write programs that have root privs, do you write code in them
> that let's a user or an anonymous script do anything?
> Of course not. You check what you've been given and only allow a
> restricted set of things to happen.
But, when you're adding software to the system (which is, essentially,
modifying the system), how do you determine "good things" from "bad
This thread is getting old. It should either get moved to geeks or
Jonathan Patschke ) "Pain and misery always hit the spot,
Elgin, TX ( knowing you can't lose what you haven't got."
USA ) --Depeche Mode, "Lilian"
More information about the rescue