John Summerfied wrote:
Mike McCarty wrote:
Let me put it differently. Root's UID is 0 - suppose I change UID 0's
User Login to 'doorknob' - first, can this be done? Second, would I
have to create a new home directory called 'doorknob'? Third, are
there any implications, doing this, for other software and/or
settings in a Linux PC? Fourth - if this shouldn't be done, can a new
user, say UID 15, be created with all the same privileges as root,
and can root then be purged?
You may have as many user names associated with UID 0 as you like.
The home directories may be set independently as you like.
I would not "purge" UID 0, but I cannot think of how that would
conflict.
There is another problem resolving UID=0 to a name
Which name?
At one point I had "john" and "summer" with the same UID and it did not
work very well at all.
Yes, I can believe that. I did some contract work for a company
doing pharmeceutical control software, which had a user with
UID 0 on UNIX like systems. There were three major flaws in
security: (1) ordinary users were forced to log in with
what was essentially root (yes, it was a different name,
and the password was different, and they didn't even know
they were logged in, but still, all the software ran with
root access, and defects could be devastating), (2) it was
difficult to ascertain just who and what actually did something
to the system, since everything was reported as "root", and
(3) remote access required security compromise when doing debug
work, since one had to log in as essentially root to do
any work.
A really big flaw in Unix design is the fact one user has the inherent
ability to do everything, the fact that the Unix security model is built
round this.
I think it goes a little deeper than this. The entire security
system is based on a very simple model: owner, trusted friends,
everyone else. So root is just a "universal owner".
The windows model is, to my mind better; where it falls down is the
implementation.
The Windows NT (and hence XP) model is superior, yes.
I used to be an MVS sysprog (20 years or so ago). The right/ability to
create new accounts was given to individuals (sure, they can create
users with any rights at all, but in fact there aren't many rights in
MVS, and on those machines people cared about security and implemented
audit trails).
Some of us sysprogs "owned" the system libraries, and it was the right
of ownership that gave us the ability to install/udate programs. And
they were protected by passwords and expiry dates, the latter requiring
intervention from operators to okay.
It was way more complicated than that, of course, but it helps
illustrate an alternative security model.
Another is the Access Control List model. I have used ACL on
more than one system. It is much more flexible, and allows
users (yes, lowly users, not "root" users) to control their
own files with as much finesse as the sys admin can control
the system files. But, of course, what one gets on one end
one loses on the other. ACL management is more complex and
time consuming than just user/group/world and root is
a pseudo owner for every file, and requires more knowledge
on the parts of those who use is, which can actually be
a disincentive to use it. ANY technique, if not used, is
inefectual.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
