[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

delegation conflict, background


Y'know, the conflict between users wanting to delegate and sysadmins wanting
to control access dates back for me to system design days of the early 1970's.

I was a sysadmin then manager of such at the CS dept at U/Utah.

I wanted to allow each user (even a lowly undergrad) to have the power to
create a sub-account of his own login -- for a friend to use.  All CPU time
would be taken from the source user's allocation, as would all memory
residency and all disk space usage.  The friend would create his own
password, so the source person wouldn't be able to invade the friend's
privacy and vice versa.

This is indefinite delegation.  However, it requires several changes to the
OS.  Most OS's (except mine at that time) have the characteristic that the
more jobs you log in, the more percentage of the CPU you get -- and none
controlled the percentage of the memory occupancy you got.  [Mine controlled
both and multiple jobs just diluted your clout.]

As long as you have no such controls in the OS, the user's ability to let
his friends have accounts amounts to giving up all sysadmin control.

As long as you retain sysadmin control, users keep loaning their passwords
to friends.

I assume that's the basis of your desire to permit delegation at all times.
That is, if we replace passwords with private keys, we will find users still
motivated to hand out copies of their private keys unless we allow
uncontrolled delegation of certified rights -- but I can't imagine syadmins
agreeing to that.

It looks like this is the kind of thing we can't solve without a change in
the nature of OS's (ie., never).

 - Carl

|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                              http://www.cybercash.com/    |
|207 Grindall Street           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103       T:(410) 727-4288     F:(410)727-4293        |