You mean like Java, C#, C and C++? Unless they all go by the "ancient" tag by now, or you are using non standard definitions of "language" or of "built in".
Actually, the article argues that Gecko is worth keeping exactly because it is no longer bloated and outdated. But to know that, one has to read the second page of the article.
Cheers,
alf
[...] Also, engineering software has to be built to a higher standard of reliability than most commercially available software. A bug in your game? Restart it. A bug in the software you use to design products? Better recall those 50000 widgets then. [...]
I take you have not been using a lot of engineering SW... Just about any popular consumer grade app I can think of boosts a reliability that puts to shame all of the CAD packages I've put my hands on (and that is a lot of CAD packages, if you are willing to take my word for it).
This also applies to most other professional grade SW that I know of. I'd say that this may be due to the fact that, since the user base is made of specialists, they can handle (grumbling) more unruly software behavior than the average user.
Time for a car analogy: Ferraris and Lamborghinis are harder to drive, more expensive to fix and break more easily and often than Fords. Yet they are way more expensive.
"How did the carpenter building his own home respond to the (voluntary) suggestions of a professional architect?"
...
That home would not be inflicted on the general public - builder and user are the one and same individual.
Besides, most bricklayers and carpenters know more about home usability than the average coder does about sw usability (this discussion adding ample evidence to this POV).
... Make it do what it says, and NOTHING else. If you want the can opener too, write another app, or put it somewhere away from the user.
Partly agree, but it's got to be more involved or Outlook (which I personally loathe) would not be the email client of choice.
...MS wizards are simple. Nobody uses them.
Dubious. I've seen several users using them. I do use some them (disk shares, network folders) myself, even when I could type "net something something something" in a cmd box. OTOH, some of "them" other wizards get actually more in the way then anything else.
...The rule should be: if you can decide for the user, don't confront him with the question, let the program figure it for the user. Allow configuration, don't force it.
(1) "Usability" is in the mind of the user. If you learned how to use some other system first and now expect that any other way of doing things isn't "usable" enough, that's just plain old resistance to change. It says more about you than it does about the usability of the software in question.
Right. Next time I buy a car sporting the clutch pedal where I am expecting to find the rearview mirror, I won't complain, lest somebody thinks I am "resisting to change".
By and large, users should just shut up and put up smiling with reams of seemingly bewildering and unjustified interface and behavior changes at the whim of the first coders, because, after all, what else have they got to do with their lives?
Coders, on the other hand, have been handed the holy task of exploring "groundbreaking new paradigms".
(2) "Designers" who can't code have absolutely no business "working" in software. If you think you really know how an interface should work and look, then learn to code it.
Right on target again. I also think that engineers who design engines and cannot turn them on a lathe (and also design and manufacture personally the molds for meting, etc.) have no business in mechanical design: why are they called "engine"ers, uh?. Also electrical engineers who cant personally ion-implant silicon wafers.
Personally, I find FBSD, Debian, Slackware, and the majority of GNU software to be quite usable...
Sort of explains most of the preceding quotes...
Look: my editor of choice, Emacs (no religion wars, please) has been hardheadedly sticking to quite a few absurd guns (Backspace is for help, Del for delete previous, Ctl-d for delete current, C-Y is paste, C-W is cut...) fore years now.
Because I adopted it in the early 90's - and even for a world where UI consistency was widely disregarded some of its choices were already quite bizarre (the C-H thingy, especially) - I'm too used to it to give it up now (even at the risk of royally screwing up in the first few seconds of an ap switch).
Today an application that attempted 1/100th of the weird modifications that Emacs does to the accepted behavior would get the boot from my app-space in one nanosecond flat. Sure, I can customize most key-sequences: that also implies I would not know my way around the plain vanilla app when I find I have to use it, so no, thanks.
And that's just beginning to scratch the surface of GNU apps that are borderline unusable even for an intended highly technical audience:
iptables (formerly ipfwadm, ipfilter... I have long ceased counting). Incompatible name and interface changes for doing exactly the same things. Lots of exposed wires and internals in the interface. Bundling of seemingly unrelated tasks (e.g. NAT and firewalling) in the same tool. etc.
raidtools, mdadm, and the whole big hairy mess of disk management tools.
SElinux, the tool every admin turns off at first boot.
And these are only the admin level things (which is mostly my territory). Though I use them sparsely, I have the feeling that userland and desktop apps tend to suffer from a similar "design" attitude.
[...] And you're not supposed to copy the.rpmsave over, you're supposed to diff both files, [...]
Yes I know that, but that's not my point. Which is: upgrades involving icompatible config changes a.k.a.rpmsave should never happen without explicit approval.
Which would give you the chance to deny it, read up on what's happened, mnerge7test the new config, and THEN deploy it. The way things are, a "slip of yum" leaves you with a disabled system until you figure out the needed changes - which may be hours.
When you roll out updates, it is ROUTINE for the new software to backup the old conf file and install a new one. This is completely standard.
Not quite. What I'd expect is a named.conf.rpmnew with the old config in place. My feeling is that the.rpmsave thing should never be done unless if explicitely accepted.
Example of why: fubar.2.0 makes a few incompatible config changes (a no-no in itself) over 1.99. Yum pulls the.rpmsave trick as part of a 25+ packages upgrade. You copy.rpmsave over. You lose. (Dovecot did this a few times).
As for having a test server where you roll out the updates I'd say that the shops that can afford to:
i) mirror all their servers to an exact replica (it has to be current and exact, or whatever testing yo do will be void).
ii) have the time and resources to run the update/test/deploy
I see no way IP can equate to physical property without infringing basically on what an individual can think, speak and do. I can tolerate that such freedoms can be restricted for a time span limited by the life of the individual(s) that conceived the work in the first place (with a possible extension for a surviving spouse): this also means that I do not see IP as a tradeable/trasferable good.
A non-software example, for the sake of diversity.
As of today, Italian musicians have to pay dues to the Italian authors and editors guild (SIAE) to perform a gig entirely consisting in (say) Cole Porter standards . These dues - that can in no way benefit Cole (R.I.P.) - seriously hamper live music performance in this country, where venue owners wanting to offer live music often find themselves owing more to the SIAE than to the performers. Now THAT makes sense.
Do I need to underline the counter economic implications of this policy, which works towards making scarce resources (live performance) even scarcer in order to prop the price of something (tunes,recordings) whose infinite reproducibility should make abundant and extremely cheap?
And of course the problem with dried peas is that babies will stick them up their noses. So you don't give dried peas to babies. Babies and professional software developers are different things, and its reasonable to have different expectations from them. Metaphors should not be stretched beyond their limits... I'm sure you had caught my drift.
Overall, its just not as hard or complicated as you make it sound. [...] You seem to be suggesting that someone should be able to write software that works on a platform without having any knowledge of the platform. Thats just silly. Look, you and I may argue 'til the cows come home about how complicated the thing is. I think it's a horrible, mad jumble, you think it's rational design, basically easy as eating cake, and nothing's gonna change it.
However, thousands of developers (developers developers developers: the same folks that made MS big and successful) have, over the years, voted with their keyboards to give an extremely wide berth to the whole winsecurity shebang. No amount of name calling (e.g. lazy scum), or UAC, is going to make *THAT* go away.
The UAC is living proof that the windows security model is way too complex for its audience (when historians need to assess the prevalence of a crime in a certain period, they look for laws forbidding it). This is what I call a (serious) design flaw. But you are welcome to call it George, if it makes you feel better.
Greetings.
[...] The problem is that the bulk of the 3rd party software developers in the ecosystem use practices that violate the published guidelines and best-practices for the platform, and often use techniques that are indistinguishable from malware. And of course the problem with dried peas is that babies will stick them up their noses. So you don't give dried peas to babies.
Making unreasonable assumptions on your user base is a design flaw that cannot really be patched by saying "users are stupid lusers" and "3d party developers are lazy, irresponsible scum" (that's the blame shifting bit, methinks).
Assuming that all developers would acquire intimate knowledge with an overengineered and horribly complex security architecture such as windows' was *NOT* realistic (we all do religiously read every system manual back to cover, right?).
That does not even begin to address the fact that the security architecture itself (and the associated guidelines) kept shifting from release to release (for example bit renaming quite a few system accounts during win2k->XP), making it even more a headache (no doubt somebody is going to point out that all that happened years ago, which is true, but, guess what, things have this way of sticking around... and past behavior DOES matter).
And (since you're gonna ask) my recipe for fostering security compliance would be a drastic semplification of the security model and associated guidelines. Make it so easy even somebody with an IQ of gravel can comply. Sure, this requires a deep OS makeover, but that's what Vista was for, right? What about windows 7?
In the meantime, everybody is learning to click "yes" on the UAC dialog real quick. Unless somebody writes an installer that disables it as as ide effect (it would not surprise me in the least).
You've got alot of this stuff close, but wrong on the details. [....] The details of part of the occurrences are either a) too long and boring b) partly forgotten or c) both. Most of the ''incidents'', however, were related to having a webapp accessing a local (long running) COM server, scheduled as such or as a service, which did - in turn - access other out-of-process servers.
[...]
Not quite. The user that the at jobs ran as had to be granted 'logon as a service' user rights. Which was reasonable at the time, as that was being invoked from the AT service.
Programs using COM need(ed) (elevated) DCOM -related privileges to invoke out-of-process servers. Under very special cases, but not generally. See above. I wish I had a dollar for every hour we spent trying to figure out DCOMCFG.exe
That ultimately is a side-effect of a windows truth. You cannot spawn a process as a user unless you know the user's password. Clearly, not the most brilliant architectural choice... In the specific case there's also a bit called "allow service to access desktop"...don't get me started on that.
Only crazy if you actually had the details right, which you dont. [...] Or maybe its just DIFFERENT from what you are used to, and you dont like to learn new things, so you choose to not learn about it. Right. I'm a lazy slob. And so are all the 3rd party device drivers and app developers which failed to "get windows security right" over the last 20 years. Too bad they did not think to hire you instead. That must include a largish part of the Microsoft engineers, witness - for instance - the countless times in which controls marked "safe for scripting" actually were not.
This is a classical case of blaming a problem on someone else's behavior. But the demography of the situation is not favorable, or we wouldn't be having this conversation.
This is not a windows-only thing BTW: SELinux, that suffers from shortcomings similar to the windows security model, is almost universlly disabled.
However, let's assume that this level of complexity is really necessary (which I do not believe for a moment).
In that case, it would also be necessary to have a reasonable way to determine which (minimal) set of rights an application needs to perform a given task (and the answer is not 'technet': a log message saying "you need privelegea A, B and C-J to do that" is more like it.). That was never the case, and, given the Vista near disaster, still isn't.
What happens is that the app fails (silently) when switching accounts (or perhaps when someone, somewhere, changes a password or tweaks a group policy) - and having divined that it must be somehow related to security, several hours are spent to try and find out which particular set of rights are now needed.
Hell, give it root, it works as a beauty.
Don't take my word for it: look for yourself at what the situation IS (different from what "it should be" if only everyone had thought of purchasing your worthy consulting services).
With regard to UAC, I'm curious to what you think is a better solution. Not that I like the current one, but I rate it as the least-worst option that I can think of, other than virtualization. Drastically simplify the permission system (with an emulation layer to preserve bacckward compatibility). A security framework that nobody understands and constantly gets in the way of getting things done is worse than useless.
For a different example, look at SELinux, as bad as windows security, for exactly the same reasons, and disabled by most every sysadmin I am aware of.
"Set SELinux=0" must be one of the most frequent instructions given on Linux these days. (As frequent as the question "How do I disable UAC?")
is changed with the "SET PROC/PRIV=..." command). Of course it should be designed differently.
It should. Because I clearly remember that (after having amusedly stared at the 3/4 screenfuls of possible privileges that could be given to your process (and wondering: which are the right ones?), everybody used to type:
Look, "decent security model" does not really apply (if targeting coders, let alone users). On Windows 2000, if I recall correctly, scheduler (cron) jobs had to be granted "Logon as a network service" to work (Huh?).
Cgi (perl) scripts would misteriously issue syntax errors if not running as Admin. Programs using COM need(ed) (elevated) DCOM -related privileges to invoke out-of-process servers. Accessing network shares from a web program (may) require *a domain account with administrative DOMAIN privileges* (that crazy or what?)
In short the entire privilege architecture under windows is a big hairy mess nobody really understands, with thousands of privileges that you need to assign to perform tasks which are ostensibly unrelated to the names the privileges themselves are given. No wonder everybody (MS included sometimes) chose the path of least resistance (sanity in this case) and went for "run as Admin". That, or spend countless frustrating hours debugging "security" issues, and building wicked installers that need create users, access domain settings, with zero chances of completing trouble free in any real environment, and that therefore no end user can successfully navigate without expert support.
Frequent popups, bearing cryptic messages (UAC) do nothing other then training 'the click on yes' speed of end users.
No, they don't. For the second week in a row, I also have seen a sharp downsteps in all of my mail/spam counters: that's message count, black and grey list activity, RCPT throttle, connection throttle (spamfiltered, relay denied and virlisted don't change much, but they have white noise type spectrum regardless).
I have two consecutive downshifts at around 17:00 MET Friday (consistent with business hours but WAY deeper then in the past) and another around 15:00 MET Saturday (unprecedented). It's like some vast spam network pulling the plug at those times...interesting. Anybody knows more about this?
I am, and I do. SET PRIV=ALL was in fact the favorite way to do anything that required elevated privileges at the lovely dollar prompt.... that is exactly the reasons that makes policy based security systems a failure (IMHO). (Windows NT security - which became the current windows security model, was originally fashioned after the VMS security model)
My problem with these models is that most of them appear to end up with a large set of rather opaque permissions ("Can create system mailbox" Uh?) whose relationship with other operations nobody appears to know, or remember - the set of operations may not even be complete, or orthogonal, who knows?
Programs end up using quite surprising privileges (e.g. running form the scheduler requires "Can login from network" privilege - this is for real), which are not documented (probably because the developer was unaware of this to begin with).
A developer finding out that a program runs as root/Administrator but fails as a lower privileged user has a hell of a time if she wants to find out the minimal set of privileges required for operations....
I could go on.
End result, all the oh-so-great multilevel policy system ends up as the old all-or-nothing horse trick.
Slashdot Mirror
In a Silent Way might be more approachable.
So would be "Kind of Blue" but I wouldn't call either "free".
You, I generously assume, are aware of the self object...
Well, if he favors C++, he calls it the this object.
[...] My definition of "built in" means "can be used with the default libraries".[...]
Your definition seems overly large to me. By this token, database access becomes a "built in" also, as does networking, XML parsing... you name it.
What about "hash tables as native data types"?
...but ist architects smoke REALLY good stuff.
You mean like Java, C#, C and C++? Unless they all go by the "ancient" tag by now, or you are using non standard definitions of "language" or of "built in".
Cheers,
alf
In fact, not to start a language war, I think his language of choice should be Perl.
Cheers,
alf
Actually, the article argues that Gecko is worth keeping exactly because it is no longer bloated and outdated. But to know that, one has to read the second page of the article. Cheers, alf
[...] Also, engineering software has to be built to a higher standard of reliability than most commercially available software. A bug in your game? Restart it. A bug in the software you use to design products? Better recall those 50000 widgets then.
[...]
I take you have not been using a lot of engineering SW... Just about any popular consumer grade app I can think of boosts a reliability that puts to shame all of the CAD packages I've put my hands on (and that is a lot of CAD packages, if you are willing to take my word for it).
This also applies to most other professional grade SW that I know of. I'd say that this may be due to the fact that, since the user base is made of specialists, they can handle (grumbling) more unruly software behavior than the average user.
Time for a car analogy: Ferraris and Lamborghinis are harder to drive, more expensive to fix and break more easily and often than Fords. Yet they are way more expensive.
Cheers,
alf
I wonder if tacked on object-oriented is a good idea in any language?
Like Javascript, you mean?
Today, you can do sysadmin stuff with php at the cli, but is it a good idea?
Not really.
P.S: I really hate regular expressions. Works? Yes, but how to explain what a hell one crazy regular expression line does on your code?
Ever tried comments? You really should.
Your analogy doesn't follow. Better would be:
"How did the carpenter building his own home respond to the (voluntary) suggestions of a professional architect?"
...
That home would not be inflicted on the general public - builder and user are the one and same individual.
Besides, most bricklayers and carpenters know more about home usability than the average coder does about sw usability (this discussion adding ample evidence to this POV).
alf
... Make it do what it says, and NOTHING else. If you want the can opener too, write another app, or put it somewhere away from the user.
Partly agree, but it's got to be more involved or Outlook (which I personally loathe) would not be the email client of choice.
...MS wizards are simple. Nobody uses them.
Dubious. I've seen several users using them. I do use some them (disk shares, network folders) myself, even when I could type "net something something something" in a cmd box. OTOH, some of "them" other wizards get actually more in the way then anything else.
...The rule should be: if you can decide for the user, don't confront him with the question, let the program figure it for the user. Allow configuration, don't force it.
Totally agree.
alf
(1) "Usability" is in the mind of the user. If you learned how to use some other system first and now expect that any other way of doing
things isn't "usable" enough, that's just plain old resistance to change. It says more about you than it does about the usability of the
software in question.
Right. Next time I buy a car sporting the clutch pedal where I am expecting to find the rearview mirror, I won't complain, lest somebody thinks I am "resisting to change".
By and large, users should just shut up and put up smiling with reams of seemingly bewildering and unjustified interface and behavior changes at the whim of the first coders, because, after all, what else have they got to do with their lives?
Coders, on the other hand, have been handed the holy task of exploring "groundbreaking new paradigms".
(2) "Designers" who can't code have absolutely no business "working" in software. If you think you really know how an interface should
work and look, then learn to code it.
Right on target again. I also think that engineers who design engines and cannot turn them on a lathe (and also design and manufacture personally the molds for meting, etc.) have no business in mechanical design: why are they called "engine"ers, uh?. Also electrical engineers who cant personally ion-implant silicon wafers.
Personally, I find FBSD, Debian, Slackware, and the majority of GNU software to be quite usable...
Sort of explains most of the preceding quotes...
Look: my editor of choice, Emacs (no religion wars, please) has been hardheadedly sticking to quite a few absurd guns (Backspace is for help, Del for delete previous, Ctl-d for delete current, C-Y is paste, C-W is cut...) fore years now.
Because I adopted it in the early 90's - and even for a world where UI consistency was widely disregarded some of its choices were already quite bizarre (the C-H thingy, especially) - I'm too used to it to give it up now (even at the risk of royally screwing up in the first few seconds of an ap switch).
Today an application that attempted 1/100th of the weird modifications that Emacs does to the accepted behavior would get the boot from my app-space in one nanosecond flat. Sure, I can customize most key-sequences: that also implies I would not know my way around the plain vanilla app when I find I have to use it, so no, thanks.
And that's just beginning to scratch the surface of GNU apps that are borderline unusable even for an intended highly technical audience:
And these are only the admin level things (which is mostly my territory). Though I use them sparsely, I have the feeling that userland and desktop apps tend to suffer from a similar "design" attitude.
Cheers,
alf
[...] And you're not supposed to copy the .rpmsave over, you're supposed to diff both files, [...]
Yes I know that, but that's not my point. Which is: upgrades involving icompatible config changes a.k.a .rpmsave should never happen without explicit approval.
Which would give you the chance to deny it, read up on what's happened, mnerge7test the new config, and THEN deploy it. The way things are, a "slip of yum" leaves you with a disabled system until you figure out the needed changes - which may be hours.
Yet another reason to run with SELINUX=0, if I ever needed more.
Cheers,
alf
When you roll out updates, it is ROUTINE for the new software to backup the old conf file and install a new one.
This is completely standard.
Not quite. What I'd expect is a named.conf.rpmnew with the old config in place. My feeling is that the .rpmsave thing should never be done unless if explicitely accepted.
Example of why: fubar.2.0 makes a few incompatible config changes (a no-no in itself) over 1.99. Yum pulls the .rpmsave trick as part of a 25+ packages upgrade. You copy .rpmsave over. You lose. (Dovecot did this a few times).
As for having a test server where you roll out the updates I'd say that the shops that can afford to:
i) mirror all their servers to an exact replica (it has to be current and exact, or whatever testing yo do will be void).
ii) have the time and resources to run the update/test/deploy
are not in the majority. This said I'd say that
yum update bind
rather than
yum -y update
would have been a lot wiser.
Cheers,
alf
I see no way IP can equate to physical property without infringing basically on what an individual can think, speak and do. I can tolerate that such freedoms can be restricted for a time span limited by the life of the individual(s) that conceived the work in the first place (with a possible extension for a surviving spouse): this also means that I do not see IP as a tradeable/trasferable good.
A non-software example, for the sake of diversity.
As of today, Italian musicians have to pay dues to the Italian authors and editors guild (SIAE) to perform a gig entirely consisting in (say) Cole Porter standards . These dues - that can in no way benefit Cole (R.I.P.) - seriously hamper live music performance in this country, where venue owners wanting to offer live music often find themselves owing more to the SIAE than to the performers. Now THAT makes sense.
Do I need to underline the counter economic implications of this policy, which works towards making scarce resources (live performance) even scarcer in order to prop the price of something (tunes,recordings) whose infinite reproducibility should make abundant and extremely cheap?
Cheers,
alf
[...]
You seem to be suggesting that someone should be able to write software that works on a platform without having any knowledge of the platform. Thats just silly. Look, you and I may argue 'til the cows come home about how complicated the thing is. I think it's a horrible, mad jumble, you think it's rational design, basically easy as eating cake, and nothing's gonna change it.
However, thousands of developers (developers developers developers: the same folks that made MS big and successful) have, over the years, voted with their keyboards to give an extremely wide berth to the whole winsecurity shebang. No amount of name calling (e.g. lazy scum), or UAC, is going to make *THAT* go away.
The UAC is living proof that the windows security model is way too complex for its audience (when historians need to assess the prevalence of a crime in a certain period, they look for laws forbidding it). This is what I call a (serious) design flaw. But you are welcome to call it George, if it makes you feel better.
Cheers,
alf
The problem is that the bulk of the 3rd party software developers in the ecosystem use practices that violate the published guidelines and best-practices for the platform, and often use techniques that are indistinguishable from malware. And of course the problem with dried peas is that babies will stick them up their noses. So you don't give dried peas to babies.
Making unreasonable assumptions on your user base is a design flaw that cannot really be patched by saying "users are stupid lusers" and "3d party developers are lazy, irresponsible scum" (that's the blame shifting bit, methinks).
Assuming that all developers would acquire intimate knowledge with an overengineered and horribly complex security architecture such as windows' was *NOT* realistic (we all do religiously read every system manual back to cover, right?).
That does not even begin to address the fact that the security architecture itself (and the associated guidelines) kept shifting from release to release (for example bit renaming quite a few system accounts during win2k->XP), making it even more a headache (no doubt somebody is going to point out that all that happened years ago, which is true, but, guess what, things have this way of sticking around... and past behavior DOES matter).
And (since you're gonna ask) my recipe for fostering security compliance would be a drastic semplification of the security model and associated guidelines. Make it so easy even somebody with an IQ of gravel can comply. Sure, this requires a deep OS makeover, but that's what Vista was for, right? What about windows 7?
In the meantime, everybody is learning to click "yes" on the UAC dialog real quick. Unless somebody writes an installer that disables it as as ide effect (it would not surprise me in the least).
Cheers,
alf
[....] The details of part of the occurrences are either a) too long and boring b) partly forgotten or c) both. Most of the ''incidents'', however, were related to having a webapp accessing a local (long running) COM server, scheduled as such or as a service, which did - in turn - access other out-of-process servers. [...]
Not quite. The user that the at jobs ran as had to be granted 'logon as a service' user rights. Which was reasonable at the time, as that was being invoked from the AT service. Programs using COM need(ed) (elevated) DCOM -related privileges to invoke out-of-process servers. Under very special cases, but not generally. See above. I wish I had a dollar for every hour we spent trying to figure out DCOMCFG.exe That ultimately is a side-effect of a windows truth. You cannot spawn a process as a user unless you know the user's password. Clearly, not the most brilliant architectural choice... In the specific case there's also a bit called "allow service to access desktop"...don't get me started on that. Only crazy if you actually had the details right, which you dont. [...]
Or maybe its just DIFFERENT from what you are used to, and you dont like to learn new things, so you choose to not learn about it. Right. I'm a lazy slob. And so are all the 3rd party device drivers and app developers which failed to "get windows security right" over the last 20 years. Too bad they did not think to hire you instead. That must include a largish part of the Microsoft engineers, witness - for instance - the countless times in which controls marked "safe for scripting" actually were not.
This is a classical case of blaming a problem on someone else's behavior. But the demography of the situation is not favorable, or we wouldn't be having this conversation.
This is not a windows-only thing BTW: SELinux, that suffers from shortcomings similar to the windows security model, is almost universlly disabled.
However, let's assume that this level of complexity is really necessary (which I do not believe for a moment).
In that case, it would also be necessary to have a reasonable way to determine which (minimal) set of rights an application needs to perform a given task (and the answer is not 'technet': a log message saying "you need privelegea A, B and C-J to do that" is more like it.). That was never the case, and, given the Vista near disaster, still isn't.
What happens is that the app fails (silently) when switching accounts (or perhaps when someone, somewhere, changes a password or tweaks a group policy) - and having divined that it must be somehow related to security, several hours are spent to try and find out which particular set of rights are now needed.
Hell, give it root, it works as a beauty.
Don't take my word for it: look for yourself at what the situation IS (different from what "it should be" if only everyone had thought of purchasing your worthy consulting services).
Cheers,
alf
For a different example, look at SELinux, as bad as windows security, for exactly the same reasons, and disabled by most every sysadmin I am aware of.
"Set SELinux=0" must be one of the most frequent instructions given on Linux these days. (As frequent as the question "How do I disable UAC?")
alf
It should. Because I clearly remember that (after having amusedly stared at the 3/4 screenfuls of possible privileges that could be given to your process (and wondering: which are the right ones?), everybody used to type:is changed with the "SET PROC/PRIV=..." command). Of course it should be designed differently.
SET PROC/PRIV=ALL
Instant root.
alf
Greetings.
Look, "decent security model" does not really apply (if targeting coders, let alone users). On Windows 2000, if I recall correctly, scheduler (cron) jobs had to be granted "Logon as a network service" to work (Huh?).
Cgi (perl) scripts would misteriously issue syntax errors if not running as Admin. Programs using COM need(ed) (elevated) DCOM -related privileges to invoke out-of-process servers. Accessing network shares from a web program (may) require *a domain account with administrative DOMAIN privileges* (that crazy or what?)
In short the entire privilege architecture under windows is a big hairy mess nobody really understands, with thousands of privileges that you need to assign to perform tasks which are ostensibly unrelated to the names the privileges themselves are given. No wonder everybody (MS included sometimes) chose the path of least resistance (sanity in this case) and went for "run as Admin". That, or spend countless frustrating hours debugging "security" issues, and building wicked installers that need create users, access domain settings, with zero chances of completing trouble free in any real environment, and that therefore no end user can successfully navigate without expert support.
Frequent popups, bearing cryptic messages (UAC) do nothing other then training 'the click on yes' speed of end users.
Cheers,
alf
No, they don't.
For the second week in a row, I also have seen a sharp downsteps in all of my mail/spam counters: that's message count, black and grey list activity, RCPT throttle, connection throttle (spamfiltered, relay denied and virlisted don't change much, but they have white noise type spectrum regardless).
I have two consecutive downshifts at around 17:00 MET Friday (consistent with business hours but WAY deeper then in the past) and another around 15:00 MET Saturday (unprecedented). It's like some vast spam network pulling the plug at those times...interesting. Anybody knows more about this?
Cheers,
alf
> anyone old enough to remember VAX/VMS?
I am, and I do.
SET PRIV=ALL was in fact the favorite way to do anything that required elevated privileges at the lovely dollar prompt.... that is exactly the reasons that makes policy based security systems a failure (IMHO). (Windows NT security - which became the current windows security model, was originally fashioned after the VMS security model)
My problem with these models is that most of them appear to end up with a large set of rather opaque permissions ("Can create system mailbox" Uh?) whose relationship with other operations nobody appears to know, or remember - the set of operations may not even be complete, or orthogonal, who knows?
Programs end up using quite surprising privileges (e.g. running form the scheduler requires "Can login from network" privilege - this is for real), which are not documented (probably because the developer was unaware of this to begin with).
A developer finding out that a program runs as root/Administrator but fails as a lower privileged user has a hell of a time if she wants to find out the minimal set of privileges required for operations....
I could go on.
End result, all the oh-so-great multilevel policy system ends up as the old all-or-nothing horse trick.
Cheers,
alf