-----BEGIN PGP SIGNED MESSAGE-----
Stewart Stremler wrote:
I think there is also the argument to be made that nobody really runs a single user system anyway. Most households I know of have several users on their computers. Mom, dad, one or two kids, etc. I think most Lindows systems will be used in that way just like most of the Windows systems I see are used that way.
But effectively, they are all the same user. My experience is that it's rare that everyone in the family doesn't have at least one other member's password. Or they all share the same "user".
Even in the business world I found this to be no uncommon. I and another maintained all the computers in fabrication shops at Ryan. At any given time, any (Machine) Operator may be running any machine and therefore needed access to the PC at that station. When each Operator (or Supervisor) had their own accounts, it was common for one Operator to munge his password. So, the process was:
1) Operator A forgets/mistypes his password. Three strikes disables his account. 2) Operator A gets Operator B's UID/PW (courtesy of Operator B) so he could run the job. 3) Operator A forgets/mistypes Operator B's password. Three strikes disables Operator B's account. ... 4) All Operator accounts are disabled through password munging.
5) Operator Z gets Supervisor's UID/PW (courtesy of Supervisor). 6) Operator Z forgets/mistypes Supervisor's password. Three strikes disables Supevisor's account. ... 7) All Operator and Supervisor accounts are disabled. 8) Supervisor finally comes to us to re-enable accounts.
So, we make just one Operator account, and one Supervisor account. One password to remember for each. Account lockouts go away, but now, for reasons related to production quotas, Operators are now running jobs as Supervisor (courtesy of Supervisors) in order maintain production levels. IOW: security violations[1].
Point is, people share accounts. Even in the workplace. Of course this might spawn a whole other thread on accountability, but suffice it to say that in the real world (home or business), especially where production (and timeliness) is the highest priority, security /still/ takes a back seat, often effectively making moot any discussion on the merits of separate users.
This is especially true of the home user. No matter the number of members using the box, for all intents and purposes, there is still effectively only one user. And no matter who actually created any given account on the box, it's data is still open to easy access and corruption or loss by any other user in the household.
That's the typical Windows home computer use. I see little reason to expect that a typical Linux home computer won't be used in the same way. No matter how many locks are put on such a system its only safe as long as /everyone/ having a key protects that key. In the context of Robertson's statements, and I think Stewart's, the assumption is made that the average home computer user will not protect one key any more than they will any other. Even on a multi-user system - as long as that system is effectively being used as a /single-user/ system as illustrated above. Therefore every account is just as secure or insecure as any other account *in actual practice on a typical home system* .
A lot of people confuse multi-user system constraints with single-user system constraints.
Feeling trolled, I posit that single-user systems are quite rare and that a distribution should be prepared to handle a multi-user system or it is failing the user.
As I said above, there is a real distinction between how a OS is /designed/ to be used and how that same OS is /actually/ used. I think Stewart's premise is that the vast majority of the unwashed masses tend to use their boxes in a single-user frame of mind.
With TWO users, the situation changes drastically. Losing just one user's data is bad, but not as bad as losing the data for BOTH users. So _system_ security becomes paramount. You protect the system so that a compromise of one user does not affect the other user.
Exactly. So, shall we proclaim that Linspire is not a multi-user system? If that is the case then that is a great argument against it I think.
Certainly it's a multi-user system, but one of the fundamental premises of this discussion is that it's probably going to be used in a single-user way. There's theory and there's practice. As a good friend of mine is fond of saying, based on experience in a completely different industry, "Safety doesn't sell".
It oughtn't.
If it does, that's a separate issue, as it's no long a single-user machine, but a server.
Every host on the Internet should be capable of being a server. That is part of the utility of the net. Linspire users will inevitably want to run P2P file sharing apps at the very least. I think we have been arguing the wrong thing all along.
You may have a point here.
You don't get sharp arguments by cheering. You get 'em by applying the whetstone of logic and contrarianess.
Sometimes it's just annoying.
And crappy arguments aren't?
I'm plenty annoyed. I've decided to be generous and share.
I have to agree with Neil that taken too far it does get annoying.
I find it educational. But then I'm not getting emotional about it.
I think it's for Stewart to show us his cards. :) Where do you really stand on the issue? As an experienced Unix guy your opinion is valued.
I think he's been pretty clear. Maybe a bit too subtle or even a bit sly, but clear nonetheless to anyone who's has been paying attention.
Seriously, we have a 'so-and-so sucks because he says something we don't agree with' and not a lot of sober analysis of the pros and cons of his position. All-or-nothing reasoning is rarely reasonable, and it's quite annoying.
I am trying to provide sober analysis of the pros and cons.
Seems to me we all are.
[1] The net result is that there are a whole lot of Apache helicopters being flown by the military (domestic and foreign) which are built with machined parts which have not gone through the proper QA processes and documentation (e.g. they are flying with parts made from proof tools rather than production tools) as mandated by the government contract.
The problem was known by management, but production had to be met. By government rules, that's called contract fraud and some people were worried about going to jail over it. Fortunately for me, the company ceased manufacturing and turned into a mostly R&D/Engineering company with manufacturing out-sourced. The means to shortcutting the process was subverting the tool management software by its users, i.e. sharing passwords.
--
Best Regards,
~DJA.-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
